Tuomas Aura: CURRENT TEXT: Section 7.3: all the text about 
discarding advertised prefixes that do not fall within 
the certified ranges, and reporting them to the admin 
as error. 

PROBLEM: This is not consistent with Section 8. Also, 
deployment of SEND will be unnecessarily difficult if 
all prefixes advertised by the same router must be 
certified on the same day. It would be better to allow 
a mixture of certified and uncertified prefixes.

PROPOSAL: A router may advertise a combination of 
certified and uncertified prefixes. The uncertified 
prefix information is treated as insecure, i.e., 
processed in the same way as insecure router 
advertisements sent by non-SEND routers. The 
processing of insecure messages is specified in 
Section 8. (Note that SEND nodes that do not attempt 
to interoperate with non-SEND nodes MAY simply discard 
the insecure information.)

ALTERNATIVE PROPOSAL: A SEND-router may advertise both 
certified and uncertified prefixes but must send 
separate router advertisements for the two types of 
prefixes.

---------------

Jari Arkko: This is another complicated issue. We have visited this
particular piece of text before, so I'm trying to keep some of the
earlier resolutions still there too... let's see if I have managed to
do it right. Here's the diff:

http://www.arkko.com/publications/send/issues/issue58diff.html

and the new text:

   7.3 Advertised Prefixes

   The router's certificate defines the address range(s) that it is
   allowed to advertise securely.  A router MAY, however, advertise a
   combination of certified and uncertified prefixes.  Uncertified
   prefixes are treated as insecure, i.e., processed in the same way as
   insecure router advertisements sent by non-SEND routers.  The
   processing of insecure messages is specified in Section 8.  Note that
   SEND nodes that do not attempt to interoperate with non-SEND nodes
   MAY simply discard the insecure information.

   Certified prefixes fall into the following two categories:

   Constrained

      If the network operator wants to constrain which routers are
      allowed to route particular prefixes, routers SHOULD be configured
      with certificates having prefixes listed in the prefix extension.
      Routers so configured SHOULD advertise the prefixes which they are
      certified to route, or a subset thereof.

   Unconstrained

      Network operators that do not want to constrain routers this way
      SHOULD configure routers with certificates containing either the
      null prefix or no prefix extension at all.

   Upon processing a Prefix Information option within a Router
   Advertisement, nodes SHOULD verify that the prefix specified in this
   option falls within the range defined by the certificate, if the
   certificate contains a prefix extension.  Options failing this check
   are treated as containing uncertified prefixes.

   Nodes SHOULD use one of the certified prefixes for stateless
   autoconfiguration.  If none of the advertised prefixes match, the
   host SHOULD use a different advertising router as its default router,
   if available.  If the node is performing stateful autoconfiguration,
   it SHOULD check the address provided by the DHCP server against the
   certified prefixes and SHOULD NOT use the address if the prefix is
   not certified.

---------------

---------------

---------------

---------------