Hi Ole,

On Sun, 17 Jan 2010 22:02:25 +0100
Ole Troan <[email protected]> wrote:

> Brian,
> 
> > It appears from the discussion that the "network administrator" is trying 
> > to get *multiple* Linksys/equivalent systems to work together with no 
> > intervention (and potentially with multiple, independent ISPs).  None of 
> > the people who I know who have such a setup with IPv4 expect this to work 
> > "out of the box" and that is what I see people trying to do here with ULAs.
> 
> not quite as complicated as that even. two CPEs routers side by side 
> (presumably connected to different ISPs). if there is a requirement that a 
> CPE router should automatically generate a ULA, should the 2 routers then 
> coordinate the ULA assignment between them.
> 
> as you say, I'm not aware of any networks like that which you can 
> auto-configure for IPv4 either. and the benefit of a single ULA prefix versus 
> two when you in any case don't have zeroconf routing.
> 
> I'm trying to get an idea what IETF consensus is for these two BBF 
> requirements. I take your opinion to be: this is not a problem we should 
> solve (it really requires a lot of other things too).
> 

Would it be much harder to solve than something like the following?

1. Router boots
2. Sends out a Router Solicitation, waits a short period for responses
3. If it gets no responses, or gets a response with no ULA
prefix(es), starts announcing it's own ULA in it's own RAs (either
initially generates one, or uses a prior generated one from storage)
4. If it gets a response containing a ULA, starts announcing that,
copying the originator's PIO parameters.

Not that we should solve it now, but I think there is value in trying
to solve it. Within reason, I think methods to make ULAs as simple
(i.e. avoid multiples), stable and available as possible should be
investigated.

Regards,
Mark.

> 
> > Fred Baker wrote:
> >> well, of course. The question isn't what the RFC was written for, it's 
> >> what it might be used for. In this case, the "network administrator" is 
> >> the person who in today's internet installs a Linksys/equivalent system in 
> >> the residence/SOHO and expects to to work before they have attached to the 
> >> ISP. It works with IPv4...
> >> On Jan 15, 2010, at 9:43 AM, Brian Haberman wrote:
> >>> Wojciech Dec (wdec) wrote:
> >>>> 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.
> >>> 
> >>> The ULA RFC was not written with the perspective that individual routers 
> >>> would automatically generate the ULA prefix and then advertise them 
> >>> (either in RAs or a routing protocol).  Rather, a network administrator 
> >>> would generate the ULA prefix using the guidelines provided, design a 
> >>> subnet model for the network, and then configure the ULA prefix + subnet 
> >>> information in the routers.
> >>> 
> >>> If a network admin wanted multiple, diverse ULA prefixes, he/she can use 
> >>> the random generation logic to generate an arbitrary number of them. 
> >>> Again, the RFC was not written with the intent of routers automatically 
> >>> generating the ULA prefix without operator intervention.
> >>> 
> >>> Regards,
> >>> Brian
> >>> 
> >>> --------------------------------------------------------------------
> >>> IETF IPv6 working group mailing list
> >>> [email protected]
> >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> --------------------------------------------------------------------
> >> http://www.ipinc.net/IPv4.GIF
> > 
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [email protected]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to