Thomas,
Sorry, I forgot one item that Wes just reminded me of. Earlier in the
day I had emailed out our new text for bullet 2 that has this new line:
"The source of an ND message is no longer used for on-link
determination, which is a change from [RFC4861]."
So the new bullet 2 that you suggested in snipped below followed by our
suggestion to add the line above to the bullet.
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].
Better?
2. The configuration of an IPv6 address, whether through IPv6
stateless address autoconfiguration [RFC4862], DHCPv6
[RFC3315], or manual configuration MUST NOT implicitly 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. The source of an ND message is no longer used
for on-link determination, which is a change from [RFC4861].
Note that the requirement for manually configured addresses is
not explicitly mentioned in [RFC4861].
Thanks.
Hemant
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Thomas Narten
Sent: Thursday, July 03, 2008 3:25 PM
To: Brian Haberman
Cc: Bob Hinden; [email protected]
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
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
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
