> -----Original Message----- > From: Ole Troan [mailto:ichiroumak...@gmail.com] On Behalf Of > Ole Troan > Sent: 13 January 2010 11:37 > To: Wojciech Dec (wdec) > Cc: ipv6@ietf.org > Subject: Re: Question: Detecting routers on a link > > Woj et al, > > > Perhaps a basic question or two: What is the purpose of the > ULA being > > advertised on the shared segment, and is the intent for the > "2nd router" > > to auto-config itself an address in the ULA space and begin > > advertising that ULA too? > > the purpose of the ULA is to provide stable addressing and > allow local traffic to continue. in the case where a global > address hasn't yet been provisioned or e.g it's lease has timed out. > > the requirements around two routers, is to avoid multiple ULA > prefixes on the link. > I certainly don't expect a router to first configure it's > interface from another router's RA to then advertise that > prefix out in an RA on that interface.
Well, so I was thinking that the ULA was there to allow some home-routing auto-setup. If the 2nd router is not intended to pick up an address from the 1's ULA, then this auto-setup scheme seems to be undone (on the assumption that one does want to reach the 2nd router from within the ULA domain). That said, since in this scenario there already is an implicit assumption of multiple prefixes being assigned to the host (at least a ULA and a global), would having *another* ULA be such a big deal? The host has to choose anyway between sourcing from 2 prefixes, so choosing between 3 doesn't seem like a massive hurdle once we solve the source address sel problem. In general, reading through the ULA rfc, while there is a fair bot of talk regarding pseudo-random ULA global-id's and use along with SLAAC, there hardly is any reference to the scenario where there can be multiple global-id's per site sourced by multiple routers. However, the presence of a subnet-id indicates that the authors did have in mind a more managed addressing assignment regime, which becomes undone in the multiple router/gateway case. > > > > Also, what is the proposed way of dealing with the case > where the "2nd > > router" stops hearing advertisements from the 1st router? There are > > some interesting failure scenarios here, which may call for a more > > elaborate router-router discovery protocol, eg VRRP. > > indeed. > > the reason for me asking the question was: > - are these requirements violating any RFC? > - as this behaviour is not covered in existing IPv6 RFCs are > they clear enough for implementors to implement? > - are these requirements sufficient to solve the whole problem? > - do we need any IETF work to cover these 'gaps'? > - is this a problem which should be solved? It would seem that VRRP addresses at least some of the behaviour. -Woj. > > cheers, > Ole > > > >> -----Original Message----- > >> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] > On Behalf > >> Of Ole Troan > >> Sent: 12 January 2010 18:51 > >> To: ipv6@ietf.org > >> Subject: Question: Detecting routers on a link > >> > >> 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 > >> > -------------------------------------------------------------------- > >> > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
