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
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
