[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [rfc2461bis] Receiving a prefix option with prefix length > 64



 > (I'd personally avoid using the magic number of 64, but anyway)

=> Why? It's a reality, at least for 2462.

 > 
 > In that case, the host can configure the on-link prefix but cannot
 > configure an address by the stateless autoconfiguration mechanism.
 > So, in this case, if the administrator fully understands 
 > what they are
 > doing, they would not set the "A" flag in the prefix information
 > option.  Even if they did set the flag, the validation check in
 > RFC2462 (or 2462bis) would reject the prefix for address
 > configuration.
 > 
 > Note that RFC2461 clearly says that a same single prefix information
 > option can be handled in terms of on-link determination and for
 > address configuration separately:
 > 
 >       Note: Implementations can choose to process the 
 > on-link aspects of
 >       the prefixes separately from the address 
 > autoconfiguration aspects
 >       of the prefixes by, e.g., passing a copy of each valid Router
 >       Advertisement message to both an "on-link" and an "addrconf"
 >       function.  Each function can then operate independently on the
 >       prefixes that have the appropriate flag set.
 > (Section 6.3.4)
 > 
 > So, I don't see any contradiction in my understanding.
 > 
 > Of course, it's a different question whether this kind of
 > configuration is practical. 

=> Exactly. I find it confusing to read about on-link determination and the 
use of short prefixes in a spec that deals with 64-bit IFIDs. We should at
least
indicate the ramifications of such configuration. Alternatively, RFC 2462
should
not talk about on-link determination since it's outside its scope.

   Well, admittedly this is unlikely happen
 > in a practical environment, and I'm not actually advocating this
 > usage.  But at the same time, I can imagine a single physical link
 > sharing the four /64 on-link prefixes where all addresses are
 > configured manually or by DHCPv6.

=> Sure, but this should be hinted at in the same sentence (I mean
DHCPv6). 

 > One last remark: the forthcoming rfc2462bis-01 will have a
 > clarification on the prefix length based on my interpretation:
 > 
 >       It is the responsibility of the system administrator to insure
 >       that the lengths of prefixes contained in Router Advertisements
 >       are consistent with the length of interface 
 > identifiers for that
 >       link type. It should be noted, however, that this does not mean
 >       the advertised prefix length is meaningless. In fact, the
 > -->   advertised length has non trivial meaning for on-link
 > -->   determination in RFC 2461 [5] where the sum of the 
 > prefix length
 > -->   and the interface identifier length may not be equal 
 > to 128. Thus,
 >       it should be safe to validate the advertised prefix 
 > length here,
 >       in order to detect and avoid a configuration error 
 > specifying an
 >       invalid prefix length in the context of address 
 > autoconfiguration.
 > 
 > this part will need another revise if my understanding is incorrect.

=> ok. 

Hesham


===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------