Re: Link addressing

[Erik Nordmark <[e-mail]>]

On 3/25/14 2:00 AM, Ole Troan wrote:
> 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.
Ole,

Agreed that the terminology we have isn't detailed enough to cover the 
finer details. It makes using SLAAC to refer to the reception of a 
prefix in a PIO with A=1. That leaves link-local address formation out 
of that definition.

We have some IID assignment and generation (modified EUI-64, static 
assignment, CGA, stable-privacy).
Then we have some set of prefixes that are already known on the router 
(fe80::/64, and also prefixes the router is configured to advertise to 
others for SLAAC).

I don't know how folks have implemented this on routers.
When we implemented this in Solaris it seemed helpful (even on a Solaris 
box configured as a router) to configure the IID separately (or get it 
from the MAC address), and then by default form the router's global 
addresses based on the prefixes the router is configured to advertise 
for SLAAC. (But NOT do anything with prefixes received in PIOs.)

The alternative would be to configure the router's advertised prefixes 
separately from the global addresses assigned to the router's 
interfaces, and that might be what other implementations do.

    Erik

>
>> 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
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------