Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

[Thomas Narten <[e-mail]>]

My. $.02.

Close to ready to ship.

Substantive:

>    In addition to the Prefix List, individual addresses are on-link if
>    they are the target of a Redirect Message indicating on-link, or the
>    source of a valid Neighbor Solicitation or Neighbor Advertisement
>    message.

Per list discussion, this last part should be dropped.


>    3.  On-link determination SHOULD NOT persist across IPv6 interface
>        initializations.  Note that section 5.7 of [RFC4862] describes
>        the use of stable storage for addresses acquired with stateless
>        address autoconfiguration with a note that the Preferred and
>        Valid Lifetimes must be retained if this approach is used.
>        However no RFC suggests or recommends retaining the on-link
>        prefixes.

Hmm. I agree that the current specs don't suggest doing this, but is
it forbidden or wrong? I.e., is caching on-link information any worse
than caching the generated addresses? The PIO has Lifetime fields, and
as long as they are honored... ANd indeed, that is what point 4
reinforces...

I don't see right off why rule 3 is needed.

>    5.  Newer implementations, which are compliant with [RFC4861] MUST
>        adhere to the following rules.  Older implementations, which are
>        compliant with [RFC2461] but not [RFC4861] may remain as is.  If
>        the Default Router List is empty and there is no other source of
>        on-link information about any address or prefix:

Hmm. When are we going to say implementations of 2461 should be fixed
and no longer support the "all destinations are on link?". Again, I
am not sure point 5 is appropriate to include here, other than perhaps
to point out that the 2461 behavior is deprecated.

Editorial:

> 1.  Introduction
> 
>    IPv4 implementations associate a netmask when an IPv4 address is
>    assigned to an interface.  That netmask together with the IPv4
>    address designates an on-link prefix.  Addresses that match this
>    prefix are viewed as on-link i.e., traffic to these addresses is not

Better:

   IPv4 implementations typically associate a netmask with an address
   when an IPv4 address is assigned to an interface. That netmask
   together with the IPv4 address designates an on-link prefix.
   Addresses that are covered by this prefix are viewed as on-link
   i.e., traffic to these addresses is not sent to a router.  See
   section 3.3.1 in [RFC1122]. Prior to the deployment of CIDR, an
   address's netmask could be derived directly from the address. In
   tha absence of specifying a specific netmask when assigning a
   address, some implementations would fall back to deriving the
   netmask from the class of the address.



>    2.  The configuration of an IPv6 address, whether through IPv6
>        stateless address autoconfiguration [RFC4862], DHCPv6 [RFC3315],
>        or manual configuration MUST NOT imply that any prefix is on-
>        link.  A host is explicitly told that prefixes or addresses are
>        on-link through the means specified in [RFC4861].  Note that this
>        requirement for manually configured addresses is not explicitly
>        mentioned in [RFC4861].
> 


Better (?):

   2.  The configuration of an IPv6 address, whether through IPv6
       stateless address autoconfiguration [RFC4862], DHCPv6
       [RFC3315], or manual configuration MUST NOT implicitely cause a
       prefix derived from that address to be treated as on-link.  A
       host considers a prefix to be on-link only through explicit
       means, such as those specified in [RFC4861] or via manual
       configuration.  Note that the requirement for manually
       configured addresses is not explicitly mentioned in [RFC4861].






--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------