Fred,

> I don't see anything in the RFC about the behavior of routers in this 
> context; in point of fact, I don't see anything about routers coming up and 
> finding each other. I would interpret that as "routers are expected to be 
> configured, manually or dynamically, as opposed to determining prefixes and 
> addresses dynamically".
> 
> It seems to me that it is very rational to consider a router as getting an 
> address on an interface in three possible ways:
>  - manual configuration
>  - DHCP [RFC 3315]
>  - via a Router Advertisement from another router
> 
> manual configuration takes precedence over dynamic configuration, and dynamic 
> configuration over an RA. But if a router has neither of the first two, then 
> I would agree that on that interface it is operating as a host until 
> something changes that.

this isn't so much about configuring an address from the prefix, but to avoid 
multiple ULAs in the network. the interface would be in router mode (but still 
send RSs to discover other routers).
nothing stopping it from configuring an address from the prefixes advertised by 
other routers, but it certainly doesn't have to do so. it would have to install 
a route for the advertised prefixes though.

it sounds like you see no conflict with RFC4861 in this behaviour. which is 
good. do you see the BBF requirements being sufficient as a solution or do you 
think the IETF should do anything here?

> 
> By that logic, it should send an RS, and with the resulting RA it should 
> configure itself with both a prefix for the interface and an address within 
> the LAN. Absent the prefix for the interface, it would have to forward 
> datagrams to the other router in order to know they belonged on the local 
> LAN. Having "inherited" that configuration, if you will, there is something 
> it should *not* do: it should not issue an RA with that prefix while it is in 
> contact with said other router, as doing so is redundant. It should only send 
> RAs if it loses contact with the original router advertising the prefix.
> 
> Note that this is suddenly not specific to ULAs; it is also true of global 
> addresses. If I have more than one router on a LAN and one is responding to 
> RS's with RAs, the others should not do so on that interface, but should 
> inherit their prefix from the router that is responding.

the scenario at least I have in my mind is for a multi-homed network. you have 
two global prefixes, one advertised by each router. but you want a single ULA 
covering the network.

cheers,
Ole


>> hi,
>> 
>> a question arose from work I'm doing with the BBF and their CPE requirements 
>> document (TR-124/WT-192). an issue has been raised with regards to a 
>> requirement about CPE routers automatically offering ULA addresses on the 
>> LAN. in the case of multiple CPE routers on a link, the suggestion is the 
>> following two requirements:
>> 
>> LAN.ADDRESSv6.       3       The device MUST send a Router Solicitation to 
>> the LAN, to determine if there
>>                                               are other routers present.     
>> MUST
>> LAN.ADDRESSv6.       4       If the device determines other routers are 
>> present in the LAN, and that another
>>                                               router is advertising a ULA 
>> prefix, the device MUST be configurable to
>>                                               automatically use this 
>> information to decide not to advertise its own
>>                                               ULA prefix.    MUST
>> 
>> any opinion on these requirements and how they compare with expected 
>> behavour as specified in RFC4861?
>> 
>> cheers,
>> Ole
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> http://www.ipinc.net/IPv4.GIF
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to