----- Original Message -----
> From: Ray Hunter <v6...@globis.net>
> To: Brian E Carpenter <brian.e.carpen...@gmail.com>
> Cc: 'Fernando Gont' <fg...@si6networks.com>; ipv6@ietf.org
> Sent: Saturday, 4 May 2013 8:16 AM
> Subject: Re: Solutions to the problem with RFC 4941
>
>> Brian E Carpenter <mailto:brian.e.carpen...@gmail.com>
>> 3 May 2013 22:16
>>
>> Exactly. I think that draft-ietf-6man-ug clarifies this to some extent,
>> as a side-effect of clarifying the U/G bits. Would it be useful to add
>> an extra sentence in that draft, simply stating that a number of
>> independent methods for forming an IID can exist?
>>
>> Brian
> Yes.
>
> I think there's potentially a number of things to consider clarifying :
>
> 1) There may be multiple independent methods for forming an IID.
>
I think there are rather than may be, as static manually configured addresses
would be a method of forming an IID, and I understand they were the motivation
for inverting the U bit.
> 2) These methods SHOULD NOT assume any exclusivity, either on a per
> link, per interface, or per prefix basis.
>
> 3) DAD is the recognised mechanism for testing whether a unicast address
> is unique.
>
It may also be worth pointing out that more generally, the prefix length
doesn't assure the presence of the other addresses within the prefix, and that
the only way to test for their presence is to probe for them them. For example,
an address with a /127 prefix length on one end of a link doesn't ensure that
the other address within the subnet either has been configured at the other end
of the link, or isn't a duplicate of the local address. So neighbor presence
discovery and DAD really need to take place for all addresses, regardless of
the prefix length.
This might also make it clearer that IPv6 addresses, when derived from link
layer addresses, aren't tightly bound to them, and that deriving them from the
link-layer address has been for operational convenience i.e.,
autoconfiguration, rather than a requirement (something I struggled with for a
while after having experienced Novell IPX, where link-layer addresses were also
used as node addresses, and there was no neighbor discovery/address resolution
protocol, as the layer 3 node portion of address was directly copied into the
link-layer destination address at the last hop).
<snip>
Regards,
Mark.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
