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

[Ole Troan <[e-mail]>]

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.

> 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, ...)?

> 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.

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.

cheers,
Ole