Re: Re: Subject: Confirming consensus on adopting draft-carpenter-6man-why64

[Ray Hunter <[e-mail]>]

Erik Nordmark wrote:
> On 3/14/14 2:22 AM, Brian E Carpenter wrote:
>>
>> Maybe my brain is twisted, but I have no problem holding the following
>> thoughts simultaneously:
>>
>> 1. The routing architecture is VLSM
>> 2. The addressing architecture includes a parameter which is the
>>     size of an IID.
>> 3. That parameter is set to 64 for all unicast prefixes not starting 
>> 000.
>> 4. Some routers are less efficient for prefixes longer than 64.
> Brian,
> I don't see any conflicts between those thoughts.
>
> Furthermore I haven't seen any documents which state that the IPv6 
> routing architecture is limited to prefixes of length 0-64, 128.
> In fact section 2.5 in RFC 4291 hints at the more general statement 
> (even though it doesn't explicitly say that this is for the purposes 
> of routing) with:
>    IPv6 unicast addresses are aggregatable with prefixes of arbitrary
>    bit-length, similar to IPv4 addresses under Classless Inter-Domain
>    Routing.
>
> So while /64 IIDs are tremendously useful, that doesn't mean that 
> routing on /127, /112 or any other length has been banned by existing 
> specifications.
>
> It might be useful to attempt to clarify the relationship between the 
> addressing architecture and routing architecture in the why64 draft, 
> since I'm sure there might be people not participating in this 
> discussion that might want to see that clarified.
>
Yes.

> Regards,
>    Erik
>

Can I ask some basic questions?

If I read http://tools.ietf.org/html/rfc5942 it states " Any assigned 
address on an interface should initially be considered as having no 
internal structure as shown in [RFC4291]."

If host implementations can ignore the prefix length contained in RA PIO 
(because all IIDs except those staring with 000 contain 64 bit IIDs as 
defined in the addressing architecture), and routers ignore RA, what is 
the point of the prefix length option in RA?

Should the prefix length in a PIO be ignored if it does not contain 64 
on a ipv6-over-foo link that specifies 64 bit IIDs? Or should the whole 
option be ignored?

Does 5942 need to be updated to say that /64 can be assumed to be the 
default IID length (to match the IPv6 addressing architecture and 
IPv6-over-foo documents?)

If hosts can only determine whether a link local address is on link by 
virtue of the fact that a local router has not forwarded it, why does it 
matter if a link local address is /10 or /64?
Why do they need to be consistent. AFAICS anything starting with 
fe80::/10 is link-local by definition in the addressing architecture.
The only thing that matters in determining whether a link local address 
is actually on link is the physical interface it was received on: not 
how it was formed. Even if you encode some sort of interface identifier 
in there, that identifier is only local to the node, not the link.

Are nodes that assume that fe80:0000:0000:0000::/64 defines the link 
local range non compliant to IPv6 standards?

What is wrong with an operating model where hosts obtain /128 addresses 
via DHCPv6 (because address assignment via DHCPv6 does not include any 
prefix length at all) and a router publishes RA with M=1 O=1 + PIO L=0 
A=0? [or no PIO]
Why would that model break if the prefix length on the router was not /64?

So why does /64 really matter (apart for the fact that some hardware 
vendors currently want to save on forwarding engine complexity by 
limiting their CAM memory size), and some address assignment mechanisms 
(which not everyone uses) swallow exactly 64 bits when assigning an IPv6 
address?

I think the draft would be very useful if it could answer those questions.

Thanks.

-- 
Regards,
RayH