Re: Link addressing (was: Re: A Plea for Architectural & Specification Stability with IPv6)

[Mark ZZZ Smith <[e-mail]>]

Hi Ole,


----- Original Message -----
> From: Ole Troan <[e-mail]>
> To: Mark ZZZ Smith <[e-mail]>
> Cc: Glen Turner <[e-mail]>; 6man WG <[e-mail]>; RJ Atkinson <[e-mail]>
> Sent: Tuesday, 25 March 2014 8:00 PM
> Subject: Re: Link addressing (was: Re: A Plea for Architectural & Specification Stability with IPv6)
> 
> Mark,
> 
> [...]
> 
>>>  routers (as defined in RFC4861) don't autoconfigure addresses using 
> SLAAC. 
>>>  that's a host function.
>> 
>>  Being pedantic, the SLAAC RFC (RFC4862) says that "it is expected that 
> routers will generate link-local addresses using the mechanism described in this 
> document."
> 
> perhaps we need better terminology here. it is useful to have a distinction 
> between addresses that are formed based on appending an interface-identifier to 
> a well-known prefix (link-local) or manually configured prefix, and how an 
> address is formed based on receiving a /64 prefix in an RA and forming an 
> address from that.
> 
> I prefer to use the term SLAAC for the latter. i.e. a host following the 
> procedure in RFC4862 section 5.5.
> 

I agree with the terminology problem. I was using "SLAAC" to mean an "address generation method" for the LL prefix, rather than the RA/PIO based address configuration method for hosts on the link, for prefixes other than LL, that is also part of "SLAAC".

>>  The question I've wondered a bit about is what is the common 
> operational or implementation practice when configuring manual addresses on 
> routers.
>> 
>>  For people who configure static addresses on router interfaces, do they 
> actively switch SLAAC off for either individual prefixes, or for the whole 
> interface? Switching SLAAC off for the whole interface means that if there is no 
> static LL address, then the interface doesn't comply with the RFC4291 
> requirement for all IPv6 interfaces to have an LL address, and can't use any 
> functions/protocols that rely on LLs. An interface probably shouldn't be 
> able to be used for IPv6 if there are no LL addresses present.
> 
> I don't understand what you mean by "switching SLAAC off" on an 
> interface. on a router does that mean sending RAs with the A-flag in PIO off? or 
> do you mean that a link-local or global address isn't formed based on an 
> automatically generated interface-id (EUI-64, privacy, stable, ...)?
> 

Just switching off the SLAAC address generation method for the LL prefix for the router's own interface LL address i.e., if there is no statically set LL address, then the interface would not have a LL address, because the router interface now does not automatically generate an LL address. 


>>  Alternatively, if SLAAC is left enabled for the LL prefix, then there is 
> likely to now be two LLs on the interface. Static configuration of an LL address 
> would usually indicate preference for its use for all LL traffic over the SLAAC 
> LL address, which may be a problem, because IIRC, RFC6724 doesn't place any 
> preference for static addresses over SLAAC addresses.
> 
> typically applications using link-local addresses, do their own source address 
> selection.
> 
> for the implementation I'm most familiar with, we only allow a single 
> link-local address per interface. by default that's based on the modified 
> EUI-64 interface-identifier, but it can be manually set to whatever you like.
> the same for global addresses. including a short-hand for specifying the length 
> of the on-link prefix.
> 

Ok, so it seems that for this implementation a static LL address replaces a SLAAC address generation method autoconfigured LL address. The issue of which LL address to use disappears because there is only ever one LL address.

On Linux for example, if you add a static LL address to an interface, the SLAAC LL address is left there, and both of them have infinite lifetimes, so lifetimes can't be used to distinguish the preference of one of the LL addresses over the other. Deleting the SLAAC LL address is possible, however there currently isn't a flag to stop it generating a new one when e.g., the interface is admin down/up'd or when the system next boots (there is an interface 'autoconf' flag, but that only disables autoconfiguration for non-LL prefixes).

> there is nothing stopping an implementation having multiple link-locals for an 
> interface, e.g. there was at some point someone advocating that every global 
> address should have a corresponding link-local. it isn't clear what the 
> benefit of having multiple link-locals on an interface would be though.
> 

While a rare situation, perhaps while renumbering from one statically configured LL addr to another to reduce disruption of things using the old LL address. In the implementation you mentioned, what impact and how severe is the impact of changing the single LL address e.g., does it cause OSPF and BGP neighbor adjacencies to be dropped and then re-established?


Thanks,
Mark.