Re: draft-bourbaki-6man-classless-ipv6-00

[Alexandre Petrescu <[e-mail]>]

Le 13/06/2017 à 15:57, Ola Thoresen a écrit :
> On 13. juni 2017 13:40, Alexandre Petrescu wrote:
> 
>>
>>
>> Le 13/06/2017 à 09:51, Ola Thoresen a écrit :
>>> On 13. juni 2017 04:22, Manfredi, Albert E wrote:
>>>
>>>> Why so, Brian? I've already described one easy technique: the host 
>>>> can create IIDs of any length, based on an algorithm that we might 
>>>> just be debating for a long time, but fundamentally can be quite 
>>>> straightforward. And then the host chooses the correct IID to use 
>>>> for SLAAC, based on the RA it just received.
>>>
>>>
>>> Some people argue in the DNS "tussle" that it might be a problem if 
>>> the host receives different DNS-info from eg. RAs and DHCP. And now 
>>> we are discussing if the host should create its LL prefix length 
>>> based on a variable in the RAs?
>>>
>>> What if multiple routers in a network announces different prefix 
>>> lengths? This would cause MUCH greater problems
>>
>> Please identify such a problem.
>>
>> In my setting, I could put a /64 and a /65 PIOs in a same RA.
>>
>> The kernel of the existing Host would self-configure an address out of
>> that /64 and ignore the /65.  The software-to-be-written in userspace
>> would consider only  the /65 and form a second address.
>>
>> What do you think breaks in this casE?
>>
> 
> 
> I am not talking about that. I am talking about the idea of deducing the 
> prefix length for _Link_Local_ addresses from the RAs.

I see, that's why.

I was talking about PIOs for GUAs or ULAs, not for LLs.

> If the link local address is randomly generated, which is the case in 
> major OSes today, there is no way to ensure that the LL you created for 
> one > /64 prefix matches the LL of a second router which also announces 
> a prefix > /64 on the same link.
> Link local needs to be /64 to ensure that you can reach all possible 
> routers on the link - unless you are going to add multiple LL addresses 
> to an interface as well.
> But then we are suddenly facing other potential issues, so I a not sure 
> that is a path we want to go...
> 
> 
> 
>>> than just getting an invalid DNS-server and would require much more 
>>> work for the operators to keep consistent throughout a complex network.
>>>
>>> I can foresee scenarios here, where one router is deployed and 
>>> announcing prefix-lengths of /80 for its public prefix.  Then
>>> another router is added do the mix, that does not have the
>>> flexibility to change the prefix-length, so it will always use /64.
>>
>> What breaks in this case?  Who complains?  I think the existing Host
>> simply ignores the /65.
>>
> 
> What /65?
> 
> The user complains, because the LL-address generated after receiving a 
> RA from router B might make router A unavailable.
> 
> 1) Router A announces a /80
> 2) Host generates an LL: fe80::AAAA:1234:abcd:4321/80
> 3) Router B announces a /64
> 4) Host generates an LL: fe80::B000:1234:abcd:4321/64 to match the 
> prefix length of the new RA
> 
> Since that /64 does not match the /80 from router A, router A is no 
> longer able to talk to the Link Local address of the Host.

I am not sure what you meant by "router A not able to talk to Host"?

I think you meant rather that Host is not able to send packets to Router 
A? (because Router A does not see the /64 of Router B).

If so (Host not able to send packets to Router A) then I think this 
might be a typical problem of source address selection.  This is 
independent of the address being of LL kind.

> But just for arguments sake.  Let the Host keep the address, but just 
> change the prefix length...
> 
> 4) Host changes its LL-prefix length to: fe80::AAAA:1234:abcd:4321/64 to 
> match the prefix length of the new RA
> 
> Then router C comes along and also wants to play, but using the prefix 
> fe80::CCCC:0:0:0/80 for its link local network.
> Now, router A and C can not talk to each other, and the host can not 
> talk to router C
> 
> Or even worse
> 
> Router D is added, with a /60 prefix length: fe80:0:0:D0::/60 - Now, the 
> Host MUST change its prefix to talk to the new router, but that will 
> make all the other routers unavailable.

Well, if the plen is made variable in an RFC it does not mean that 
people will add buttons to their computers and play them daily like 
tuning an FM radio.  But if they do, it's at their risk :-)

> In a dynamic network, with more than one router, you simply must have 
> the same prefix length for all link local addresses, and just keeping it 
> a /64 is much easier than trying to create a new algorithm to solve all 
> potential pitfalls of using different prefix lengths for Link Local.

Err... I tend to agree.  But I think too that in a dynamic network 
computers may agree somehow dynamically on a plen to use.
An example of it is a seed in the SLAAC RFC which says that a router may 
interpret a prefix of another router, but left unsepcified.  Another 
seed is the agreement Home Agents establish when exchanging router 
advertisements, or BGP routers, or VRRP, or others.

I also tend to think that it may be easier to leave fe80::/10 (not 
fe80::/64) as a constant and not put it in RA.  But maybe we can look at 
it closer.

Alex

> 
> 
> Rgds.
> 
> Ola Thoresen
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------