Suresh Krishnan a écrit :
On 18/02/09 04:38 PM, JINMEI Tatuya / 神明達哉 wrote:
Because the specification is written that way. From a pure
technical point of view, we could have introduced a new rule, e.g.,
"if the length of a prefix with A=1 is less than 128 - length of
IID, the host should continue configuring an address with the
prefix and the IID, filling in the remaining bits with 0". My
whole point is that it's not worth the time and process overhead to
consider introducing such an additional extension at this stage
without a strong reason, and 'we could do it, why not' is (IMO) way
too weak a reason.
+1. In addition, nothing prevents a compliant router implementation
from getting a P::/56 using DHCP-PD and zeroing out the next 0 bits
in announcing a P::/64 on the pertinent link. This will achieve
everything you want.
Well yes, maybe two prefixes in an RA may be inefficient.
But now that we talk DHCPv6 PD. What /64 will the requesting and
delegating router advertise on their own interfaces (knowing the method
is to delegate several /64s out of /60 which are themselves several out
of a /56):
(SERVER)--R1--R2--(ENDHOST)
56 60 64
Were the /64 SLAAC Ethernet limit removed, the figure would make a lot
of sense, otherwise I'm forced to draw it as:
(SERVER)--R1--R2--(ENDHOST)
56 60 64
64 64 64
Which is prone to many misinterpretations.
Alex
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
