Subject: Question: Detecting routers on a link

From: Ole Troan <[email-masked]>
Date: Tue, 12 Jan 2010 18:50:31 +0100

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

---

From: Fred Baker <[email-masked]>
Date: Tue, 12 Jan 2010 18:09:20 -0800

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.

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.

On Jan 12, 2010, at 9:50 AM, Ole Troan wrote:

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

http://www.ipinc.net/IPv4.GIF

---

From: Ralph Droms <[email-masked]>
Date: Tue, 12 Jan 2010 21:07:53 -1000

Ole - I have a problem with some of the terminology in the  
requirements: specifically, the use of "LAN" is ambiguous and should,  
I think, be replaced with some more specific like "to all links on  
which the device has an active interface".

One issue with this mechanism is what to do if the "ULA-router"  
flaps?  Will another router begin to advertise a new ULA?  Will the  
original router honor the new ULA and refrain from advertising its own  
ULA when it comes back up?  All of which leads to a "ULA-flap" in the  
subscriber network, which seems like a bad event.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Tue, 12 Jan 2010 21:09:57 -1000

Fred - I disagree with:

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

If the subscriber network is multihomed, with different prefixes from  
different SPs, should each router advertise its own prefixes?

- Ralph

On Jan 12, 2010, at 4:09 PM 1/12/10, Fred Baker wrote:

> 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".
>
> 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.
>
> 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.
>
>> 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:
>>
>> any opinion on these requirements and how they compare with  
>> expected behavour as specified in RFC4861?
>>
>> cheers,
>> Ole

---

From: Fred Baker <[email-masked]>
Date: Tue, 12 Jan 2010 23:15:03 -0800

On Jan 12, 2010, at 11:09 PM, Ralph Droms wrote:

> If the subscriber network is multihomed, with different prefixes  
> from different SPs, should each router advertise its own prefixes?

If I am a router that knows its address per DHCP, that takes  
precedence over learning it from an RA.

What I'm talking aobut is the situation of "Home RTR" in figure 3 of http://tools.ietf.org/html/draft-baker-ipv6-prefix-subdelegation 
  on its interface facing CPE RTR ISP #1 and #2. I submit that from  
each of the CPE routers, it should learn a prefix - because each of  
those has a prefix already assigned. One could imagine it also asking  
them what prefixes it should assign as prefix:2..prefix:7.

>> 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".
>>
>> 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  
>> would have to forward datagrams to the other router in order to  
>> know they belonged on the local LAN. Having "inherited" that  
>> 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

---

From: Mark Smith <[email-masked]>
Date: Wed, 13 Jan 2010 17:46:40 +1030

On Tue, 12 Jan 2010 21:07:53 -1000

> subscriber network, which seems like a bad event.

IIRC, Appletalk did this sort of thing, with "seed" routers etc. It
might be worth seeing if it dealt with these sorts of situations, and
how.

Another related issue, although not so much of one with small
residential/SOHO offices, is if a router configures it's local
interface with prefixes in other routers' RAs, should the learning
router then automatically announce those prefixes into any IGPs or EGPs
its operating? I think Appletalk did, however these days I'd think it'd
be better not to.

Regards,
Mark.

---

From: Fred Baker <[email-masked]>
Date: Tue, 12 Jan 2010 23:31:42 -0800

My initial sense... for SPF-based protocols (OSPF/IS-IS) it actually  
makes little difference whether they do or don't. If they are  
forwarding directly to host in their subnet (my preferred term for  
what Ole calls a LAN), and only the router beyond them is advertising  
the prefix, they will in the normal case be the router en route to the  
advertising router. As such, while it is possible to construct  
exception cases, For SPF-based protocols it is sufficient of only the  
router they learned it from advertises the prefix.

Distance vector protocols like RIP are a different case because we now  
have to put a funny case in them - "if I learned it from another  
router in the subnet but I am in the same subnet, ..." In distance  
vector protocols, yes, they should advertise it away from the subnet.

---

From: Mark Smith <[email-masked]>
Date: Wed, 13 Jan 2010 18:34:37 +1030

Hi Fred,

On Tue, 12 Jan 2010 23:31:42 -0800

> vector protocols, yes, they should advertise it away from the subnet.

I should have qualified my thoughts. My concern was a security one -
it'd probably be possible to inject a large number of malicious
RAs with differing prefixes. I think having 'learning' routers not
inject those prefixes into IGPs or EGPs automatically would prevent the
consequences off the attack from propagating past the local
subnet. Of course that's a threat we have today, which we mitigate
with authenticated routing information, so only learning and using
prefixes from trusted peer routers' RAs would overcome my concern. In
the likely residential CPE context of what Ole raised, having
residential end-users being capable of setting up trust relationships
between routers might be a bit of an ask unfortunately.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 13 Jan 2010 11:27:29 +0100

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?

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.

-Woj.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ole Troan
> Sent: 12 January 2010 18:51
> To: [email-masked]
> 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
>

---

From: Ole Troan <[email-masked]>
Date: Wed, 13 Jan 2010 11:37:16 +0100

Woj et al,

> to auto-config itself an address in the ULA space and begin advertising

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.

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

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 13 Jan 2010 11:43:49 +0100

Ralph,

> Ole - I have a problem with some of the terminology in the requirements: specifically, the use of "LAN" is ambiguous and should, I think, be replaced with some more specific like "to all links on which the device has an active interface".

there is a wish to have terminology which makes a distinction between WAN facing (towards the SP) and customer facing interfaces. but note that this isn't _my_ terminology and I take no responsibility for it. ;-)

> One issue with this mechanism is what to do if the "ULA-router" flaps?  Will another router begin to advertise a new ULA?  Will the original router honor the new ULA and refrain from advertising its own ULA when it comes back up?  All of which leads to a "ULA-flap" in the subscriber network, which seems like a bad event.

correct. so as I said to Woj are these requirements complete? do we need new protocol work or an IETF specification describing how this should work? is it a problem we need to resolve? e.g could we just say that having two ULA prefixes in the network is fine. or we just state that this is a problem which require manual configuration?

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 13 Jan 2010 11:48:14 +0100

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

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 13 Jan 2010 12:11:07 +0100

> From: Ole Troan [mailto:[email-masked]] On Behalf Of 
> Ole Troan
> Sent: 13 January 2010 11:37
> To: Wojciech Dec (wdec)
> Cc: [email-masked]
> Subject: Re: Question: Detecting routers on a link
> 
> Woj et al,
> 
> > 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.
> 
> 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.

> > 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.
> 
> - as this behaviour is not covered in existing IPv6 RFCs are 
> they clear enough for implementors to implement?

It would seem that VRRP addresses at least some of the behaviour.

-Woj.

> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> >> Of Ole Troan
> >> 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:
> >> 
> advertising 
> 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
> >>

---

From: Mark Smith <[email-masked]>
Date: Wed, 13 Jan 2010 21:54:59 +1030

On Wed, 13 Jan 2010 12:11:07 +0100

> (on the assumption that one does want to reach the 2nd router from

I think there is value in having ULA prefixes as stable as possible, to
ensure ongoing local communications aren't disrupted. Two routers
announcing the same ULA prefix would help minimise or eliminate that
sort of disruption should one of them become unavailable.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 13 Jan 2010 05:51:43 -1000

Fred - are you considering a multi-homed network or a network with one  
edge router and at least one additional internal router?

- Ralph

On Jan 12, 2010, at 9:15 PM 1/12/10, Fred Baker wrote:

> those has a prefix already assigned. One could imagine it also  
> asking them what prefixes it should assign as prefix:2..prefix:7.
>
>> - Ralph
>>
>>> "routers are expected to be configured, manually or dynamically,  
>>> as opposed to determining prefixes and addresses dynamically".
>>>
>>> should configure itself with both a prefix for the interface and  
>>> an address within the LAN. Absent the prefix for the interface, it  
>>> 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.
>>>

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 13 Jan 2010 18:12:10 -0500

Hi Ole,

>                                                 automatically use this information to decide not to advertise its own

The IPv6 router implementations that I have worked on do not send RSs on 
their advertising interfaces but I did not find this behavior prohibited 
by RFC4861. So I think you can get away with doing it and still be 
compliant.

On the idea itself, I think this is probably overkill. I can see the 
intent of these requirements (avoid multiple ULA prefixes in the "LAN") 
but I do not know why this restriction is needed. I cannot see any 
issues if both the routers advertise different ULAs and hosts configure 
multiple ULA addresses (one out of each prefix).

Thanks
Suresh

---

From: Fred Baker <[email-masked]>
Date: Wed, 13 Jan 2010 15:36:32 -0800

stepping away from ULAs, I should think the point is to propagate  
routing configuration information throughout a small zero-config  
network. The several routers on a given LAN want to be in the same  
subnet; if there are several subnets on the same LAN, with the  
possible exception of DMZ routers to specific ISPs, they want to each  
be in all of them. ULA management is special case of this.

Going back to the figure I referenced (figure 3 of http://tools.ietf.org/html/draft-baker-ipv6-prefix-subdelegation) 
, you have a single LAN with five routers on it, plus LANs beyond  
three of those. Two of the routers connect to ISPs and presumably get  
prefixes delegated to them by those ISPs. In addition, to cover the  
case in which one has no connectivity to either ISP (and therefore no  
prefix lease from them), one needs a ULA. So in this network, thee is  
a need for three prefixes, two of which are global, plus link-local  
addressing. On each LAN, apart from local policy that might have one  
of the offices using one ISP and the other using the other ISP or some  
such thing, you want an IP subnet from each of those prefixes, and you  
want all of the routers on the LAN in each subnet, with the possible  
exception of the two ISP-facing routers being in each other's  
delegated prefixes.

This can be accomplished by manual configuration, by a DHCP option  
that to my knowledge is not currently defined, or by listening to each  
other's RAs as I suggested. How would you suggest achieving it?

As to what to do when one loses connectivity to the critical router,  
and again considering such a network, there are some interesting  
issues. I tend to think the best bet is to use some form of lease  
concept rather than making the prefix suddenly go away throughout, but  
can be argued into other positions.

---

From: Fred Baker <[email-masked]>
Date: Wed, 13 Jan 2010 15:38:48 -0800

I'm considering a more general case, as in my previous note. I do't  
see ULAs as a general case; they are a specific case of a larger  
problem. And I think we should solve the multihomed case and let  
single-homing be a special case of that. The point is that you have  
some number of active prefixes (two in a single-attached domain, N+1  
in a multihomed domain), and you want the prefixes distributed  
correctly.

On Jan 13, 2010, at 7:51 AM, Ralph Droms wrote:

> Fred - are you considering a multi-homed network or a network with  
> one edge router and at least one additional internal router?
>
> - Ralph
>
>
>> What I'm talking aobut is the situation of "Home RTR" in figure 3  
>> of http://tools.ietf.org/html/draft-baker-ipv6-prefix-subdelegation  
>>>> 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".
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Thu, 14 Jan 2010 16:19:19 +0100

> From: Fred Baker (fred) 
> Sent: 14 January 2010 00:37
> To: Wojciech Dec (wdec)
> Cc: Ole Troan; [email-masked]
> stepping away from ULAs, I should think the point is to 
> propagate routing configuration information throughout a 
> small zero-config network. The several routers on a given LAN 
> want to be in the same subnet; if there are several subnets 
> on the same LAN, with the possible exception of DMZ routers 
> to specific ISPs, they want to each be in all of them. ULA 
> management is special case of this.
> 
> Going back to the figure I referenced (figure 3 of 
> http://tools.ietf.org/html/draft-baker-ipv6-prefix-subdelegation)
> , you have a single LAN with five routers on it, plus LANs 
> beyond three of those. Two of the routers connect to ISPs and 
> presumably get prefixes delegated to them by those ISPs. In 
> addition, to cover the case in which one has no connectivity 
> to either ISP (and therefore no prefix lease from them), one 
> needs a ULA. So in this network, thee is a need for three 

There are a couple of aspects here in my opinion:

1. We seem to be trying to find a solution to the automated-coordination
of prefix assignment in a multi router network. This is a worthy goal,
but discussing it in the context of RA with PIO suppression to me at
least means that we're only looking at part of a solution, with other
parts like DHCP or some other method not covered.
2. Figure 3 describes a scenario with no directly attached hosts.
Advertising in RAs any PIO (ULA or other) from the two CPE RTRs would
make sense if the intent was for them to auto-address the routers
themselves, which I think would be of some value in this figure in terms
of users being able to reach these devices. However I don't quite see
why the number of ULAs actually matters much. 
3. If we want to cast the problem in terms of trying to coordinate the
whole customer site to use the same ULA (eg same global-id across the
sire), then this requires some other means beyond RA suppression for
getting the downstream customer routers to also advertise the correct
ULA and suppress their own. Short of inventing RA delegation, going with
what's already defined (eg DHCP PD) it would make sense to have the
non-suppressed router set itself up as a DHCP DR with the ULA. 

So, to put my original question differently: What is the intent of
suppressing a router from sending out an RA with a ULA in the presence
of another router advertising a ULA?
This would appear to be very specific to ULAs as it's clear that any ISP
delegated prefixes are more or less always meant to make their way to
address the end-hosts, but for ULAs (as in figure 3) that's not
necessarily the case.

-Woj.

> prefixes, two of which are global, plus link-local 
> addressing. On each LAN, apart from local policy that might 
> have one of the offices using one ISP and the other using the 
> other ISP or some such thing, you want an IP subnet from each 
> of those prefixes, and you want all of the routers on the LAN 
> in each subnet, with the possible exception of the two 
> ISP-facing routers being in each other's delegated prefixes.
> 
> This can be accomplished by manual configuration, by a DHCP 
> option that to my knowledge is not currently defined, or by 
> listening to each other's RAs as I suggested. How would you 
> suggest achieving it?
> 
> As to what to do when one loses connectivity to the critical 
> router, and again considering such a network, there are some 
> interesting issues. I tend to think the best bet is to use 
> some form of lease concept rather than making the prefix 
> suddenly go away throughout, but can be argued into other positions.
>

---

From: Fred Baker <[email-masked]>
Date: Thu, 14 Jan 2010 08:02:58 -0800

> 2. Figure 3 describes a scenario with no directly attached hosts.

I figured they were clutter in a picture that was trying to describe a  
network. If you like, I can add some number of hosts on every LAN and  
some multi-homed.

> why the number of ULAs actually matters much.

Two points here. The purpose of a ULA is to provide routing  
connectivity throughout a domain, just as the purpose of a global  
prefix is. We could have every router invent its own ULA and inject it  
in routing, but that seems like a waste given that a ULA prefix is by  
definition a /48, giving the network the ability to address 65K  
subnets within the domain. I'll ask the opposite. What is the value of  
having multiple ULAs in a domain apart from specific desires for that  
for some administrative reason?

As I said, the issue is distribution and agreement on prefixes, not  
the special case of ULA prefixes.

> non-suppressed router set itself up as a DHCP DR with the ULA.

That may well be the right way to handle sub-delegation of prefixes  
generally. There are issues in that, though - how do we ensure that  
the routers that share a LAN share a subnet, as opposed to selecting  
different ones? For example, if we presume that the delegating  
application tells one of the other routers to use prefix:1:: on  
"interface 1" and prefix:2:: on "interface 2", how does it know what  
the router it is configuring considers to be "interface 1" and  
"interface 2"? The simplest way I can thin of is to have the  
downstream router observe the use of a given subnet on a LAN and use  
the DHCP message as guidance on what to expect.

> of another router advertising a ULA?

In my opinion, the CPE Router Design Team would like to have at most  
one ULA in use in a SOHO/residential domain, and the question is about  
achieving that. I think the question is too limited; to my mind, the  
question also applies to rational use of global prefixes delegated  
from some set of ISPs.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 14 Jan 2010 07:29:52 -1000

Fred - your figure three and your e-mail describes the general case.   
I'm a little confused by your use of the terms "LAN" and "subnet".  A  
couple of questions come to mind...

A ULA for the site network is a special case, because (ideally, I  
think), one CPE RTR (terminology from figure 3) needs to generate the  
ULA for the site network.  If there is more than one CPE RTR, care  
must be taken to generate one ULA for the site and to keep that ULA  
consistent (as much as possible) over time.

Let me try to write out your three configuration scenarios in more  
detail.

On the "root" link in figure 3 ("prefix:0"), if there are three  
prefixes for the site network, say, ISP1::/48, ISP2::/48 and ULA::/48,  
then that root link would be assigned ISP1:0::/64 (pls give me  
suspension of disbelief for notation here), ISP2:0::/64 and ULA: 
0::/64.  Further suppose "CPE RTR ISP 1" has been in some way  
designated as the ULA source for the site network.  Each of the  
routers presumably needs an address from each of the three prefixes on  
its interface to the root link.  As you wrote, those addresses could  
be provided through manual assignment, DHCP or RS/RA/SLAAC:

* manual - all interfaces are assigned manually
* DHCP
  - CPE RTR ISP 1 assigns an address from ISP1:0::/64 and ULA:0::/64 to
    its interface and acts as a DHCP server for ISP1:0::/64 and ULA: 
0::/64
  - CPE RTR ISP 2 assigns an address from ISP2:0::/64 to its interface
    and acts as a DHCP server for ISP2:0::/64
  - the CPE RTRs and the Office RTRs all perform DHCP on the root link;
    CPE RTR ISP 2 and the Office RTRs receive addresses from ISP1:0::/64
    and from ULA:0::/64 from CPE RTR ISP 1; CPE RTR ISP 1 and the Office
    RTRs receive an address from ISP2:0::/64 from CPE RTR ISP 2
* RS/RA/SLAAC
  - CPE RTR ISP 1 assigns an address from ISP1:0::/64 and ULA:0::/64 to
    its interface; acts as a DHCP server for ISP1:0::/64 and ULA:0::/64;
    sends RAs advertising and specifying SLAAC on ISP1:0::/64 and ULA: 
0::/64
  - CPE RTR ISP 2 assigns an address from ISP2:0::/64 to its interface;
    acts as a DHCP server for ISP2:0::/64; sends RAs advertising and
    specifying SLAAC on ISP2:0::/64
  - the CPE RTRs and the Office RTRs all receive RAs on the root link;  
they each
    use SLAAC to assign addresses from the advertised prefixes

The only way I know to get the prefixes for the links labeled "prefix: 
[234567]" in figure 3 is through DHCP-PD.  In this case, CPE RTR ISP 1  
acts as a DHCP-PD server for ISP1:0::/64 and ULA:0::/64 and CPE RTR  
ISP 2 acts as a DHCP-PD server for ISP2:0::/64.  The Office RTRs will  
receive delegated prefixes from both CPE RTRs and configure each of  
those "downstream" links with, e.g., ISP1:2::/64, ISP2:2::/64 and ULA: 
2::/64.  Note that I don't think RFC 3633 (DHCP-PD) allows for  
interaction with multiple DHCP-PD servers, so this scenario needs some  
extensions to RFC 3633.

Getting back to the ULA issue, if there is to be just one ULA, then  
the CPE RTRs have to elect a ULA source and have a mechanism for ULA  
persistence in case the ULA source fails.  I suppose multiple ULAs in  
the site network would avoid the election and persistence issues at  
the cost of extra prefixes and complexity?

The various routers need some way to know which role they are playing  
and which configuration mechanism to use.  There also may be a need to  
exchange routing/forwarding information about the routers.

- Ralph

On Jan 13, 2010, at 1:36 PM 1/13/10, Fred Baker wrote:

> possible exception of DMZ routers to specific ISPs, they want to  
> each be in all of them. ULA management is special case of this.
>
> three of those. Two of the routers connect to ISPs and presumably  
> get prefixes delegated to them by those ISPs. In addition, to cover  
> the case in which one has no connectivity to either ISP (and  
> therefore no prefix lease from them), one needs a ULA. So in this  
> network, thee is a need for three prefixes, two of which are global,  
> plus link-local addressing. On each LAN, apart from local policy  
> that might have one of the offices using one ISP and the other using  
> the other ISP or some such thing, you want an IP subnet from each of  
> those prefixes, and you want all of the routers on the LAN in each  
> subnet, with the possible exception of the two ISP-facing routers  
> being in each other's delegated prefixes.
>
> that to my knowledge is not currently defined, or by listening to  
> each other's RAs as I suggested. How would you suggest achieving it?
>
> concept rather than making the prefix suddenly go away throughout,  
> but can be argued into other positions.
>

---

From: Fred Baker <[email-masked]>
Date: Thu, 14 Jan 2010 10:39:33 -0800

On Jan 14, 2010, at 9:29 AM, Ralph Droms wrote:

> Fred - your figure three and your e-mail describes the general  
> case.  I'm a little confused by your use of the terms "LAN" and  
> "subnet".  A couple of questions come to mind...

To me, a LAN is an instance of some lower layer networking technology,  
such as an Ethernet or a WiFi; where a lawyer might have defined it as  
a network that doesn't cross a legal boundary (for which reason we  
don't call Frame Relay or ATM networks "LANs" but rather "WANs"), RFC  
872 defines it as

           The second thing we need to know is somewhat less
      straightforward:  A LAN is, properly speaking [2], a
      communications mechanism (or subnetwork) employing a transmission
      technology suitable for relatively short distances (typically a
      few kilometers) at relatively high bit-per-second rates
      (typically greater than a few hundred kilobits per second) with
      relatively low error rates, which exists primarily to enable
      suitably attached computer systems (or "Hosts") to exchange bits,
      and secondarily, though not necessarily, to allow terminals of
      the teletypewriter and CRT classes to exchange bits with Hosts.

A subnet is a set of interfaces that are assigned IP addresses within  
the same prefix and can communicate without the intervention of an IP  
router; some are "broadcast" (all of the interfaces can talk with each  
other) and some are non-broadcast (they use the same lower layer  
network but may not all have direct connectivity to each other). The  
first use of the term in the RFC series is in RFC 61, and is used  
synonymously with "subnetwork" in many RFCs prior to RFC 1000. The  
term as we use it today, to refer to hierarchical structure within a  
site prefix, probably derives from IEN 82 (1979), which describes the  
MIT LCS Net Address Format, and in so doing describes having "subnets"  
within the MIT campus that were not separately advertised to the  
ARPANET, but advertised as a single block network. It is commented on  
in a way more like a definition in RFCs 891 and 898; 898 reports that

       Postel:  A description of the gateway implemented at MIT.  The
       gateway was first developed by Noel Chiappa.  It is written in C.
       The MIT environment has 32 internal networks which are treated as
       subnets of the MITNET on the Internet.  The MIT gateways then do
       subnet routing in their interior protocol.  The subnet routing
       scheme is similar to GGP.  Liza has added an EGP implementation  
to
       this gateway.

Jeff Mogul and others generalized that in RFCs 917, 922, 932, 936,  
940, and 950, and it finally got defined in a form we would recognize  
today in RFCs 1122, 1123, and 1812.

I think the term "subnet" is well understood in our context.

> think), one CPE RTR (terminology from figure 3) needs to generate  
> the ULA for the site network.  If there is more than one CPE RTR,  
> care must be taken to generate one ULA for the site and to keep that  
> ULA consistent (as much as possible) over time.

I think the CPE Router Design Team agrees with that statement. They're  
asking whether 6man agrees with it.

> prefixes for the site network, say, ISP1::/48, ISP2::/48 and ULA::/ 
> 48, then that root link would be assigned ISP1:0::/64 (pls give me  
> routers presumably needs an address from each of the three prefixes  
> on its interface to the root link.  As you wrote, those addresses  
> could be provided through manual assignment, DHCP or RS/RA/SLAAC:
>
> The only way I know to get the prefixes for the links labeled  
> "prefix:[234567]" in figure 3 is through DHCP-PD.

That is probably true. My question is: which interface should those  
prefixes be assigned to?

                    /-------+-/   /
                    prefix:2|     |
                        +---+--+  |
                        |Office|  |
                        |RTR 1 +--+                 --
                        +---+--+  |  +-------+     /
                    prefix:3|     |  |CPE RTR|    |
                    /-------+-/   +--+ISP 1  +------ ISP 1
                                  |  +-------+    |
                    /-------+-/   |p               \
                    prefix:4|     |r                --
                        +---+--+  |e
                        |Office|  |f
                        |RTR 2 +--+i
                        +---+--+  |x
                    prefix:5|     |:                --
                    /-------+-/   |0 +-------+     /
                                  |  |CPE RTR|    |
                    /-------+-/   +--+ISP 2  +------ ISP 2
                    prefix:6|     |  +-------+    |
                        +---+--+  |                \
                        |Home  |  |                 --
                        |RTR   +--+
                        +---+--+  |
                    prefix:7|     |
                    /-------+-/   /

                           Figure 3: Complex SOHO

In this diagram, the network is conveniently tree-structured. Let me  
throw a ringer in here; the even numbered subnets are discovered to be  
WiFi using the same SSID, so that the picture really looks like:

             /                   /
             |                   |
             |prefix:2 +------+  |
             +---------|Office|  |
             |         |RTR 1 +--+                 --
             |         +---+--+  |  +-------+     /
             |     prefix:3|     |  |CPE RTR|    |
             |     /-------+-/   +--+ISP 1  +------ ISP 1
             |                   |  +-------+    |
             |                   |p               \
             |                   |r                --
             |prefix:4 +------+  |e
             +---------|Office|  |f
             |         |RTR 2 +--+i
             |         +---+--+  |x
             |     prefix:5|     |:                --
             |     /-------+-/   |0 +-------+     /
             |                   |  |CPE RTR|    |
             |                   +--+ISP 2  +------ ISP 2
             |                   |  +-------+    |
             |prefix:6 +------+  |                \
             +---------|Home  |  |                 --
             |         |RTR   +--+
             |         +---+--+  |
             |     prefix:7|     |
             |     /-------+-/   /
             /
                   Figure 3++: Incredibly Complex SOHO

You note that the same LAN now has three prefixes on it - and not just  
three, but three subnets of the common ULA, three subnets of ISP#1's  
prefix, and three subnets of ISP#2's prefix. I submit that this might  
just possibly be overkill, but there is no way apart from  
configuration for the CPE RTR's to discern that.

I submit that therefore DHCP can't solve that, at least at the level  
of technology as it exists today. However, OR#1, OR#2, and HR can hear  
each other asserting RAs on it, and can sort it out among themselves.

> In this case, CPE RTR ISP 1 acts as a DHCP-PD server for ISP1:0::/64  
> and ULA:0::/64 and CPE RTR ISP 2 acts as a DHCP-PD server for  
> ISP2:0::/64.  The Office RTRs will receive delegated prefixes from  
> both CPE RTRs and configure each of those "downstream" links with,  
> e.g., ISP1:2::/64, ISP2:2::/64 and ULA:2::/64.  Note that I don't  
> think RFC 3633 (DHCP-PD) allows for interaction with multiple DHCP- 
> PD servers, so this scenario needs some extensions to RFC 3633.
>
> persistence in case the ULA source fails.  I suppose multiple ULAs  
> in the site network would avoid the election and persistence issues  
> at the cost of extra prefixes and complexity?
>
> The various routers need some way to know which role they are  
> playing and which configuration mechanism to use.  There also may be  
> a need to exchange routing/forwarding information about the routers.

Understood. I submit that we have enough mechanism to achieve that if  
we use it creatively.

>> network, thee is a need for three prefixes, two of which are  
>> global, plus link-local addressing. On each LAN, apart from local  
>> policy that might have one of the offices using one ISP and the  
>> other using the other ISP or some such thing, you want an IP subnet  
>> from each of those prefixes, and you want all of the routers on the  
>> LAN in each subnet, with the possible exception of the two ISP- 
>> facing routers being in each other's delegated prefixes.
>>
>> interesting issues. I tend to think the best bet is to use some  
>> form of lease concept rather than making the prefix suddenly go  
>> away throughout, but can be argued into other positions.
>>

---

From: Brian Haberman <[email-masked]>
Date: Fri, 15 Jan 2010 12:43:33 -0500

> 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

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Jan 2010 09:55:12 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Suresh Krishnan
> Sent: Wednesday, January 13, 2010 3:12 PM
> To: Ole Troan
> Cc: [email-masked]
> > 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

This matches my understanding of how router and prefix
discovery should work when there are multiple routers
on the link advertising different prefixes.

Fred
[email-masked]

---

From: Fred Baker <[email-masked]>
Date: Fri, 15 Jan 2010 10:23:19 -0800

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:

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

---

From: Brian Haberman <[email-masked]>
Date: Fri, 15 Jan 2010 13:33:57 -0500

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.

Brian

Fred Baker wrote:
> 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...
> 
>> 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.
>>

---

From: Ole Troan <[email-masked]>
Date: Sun, 17 Jan 2010 22:02:25 +0100

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

cheers,
Ole

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

---

From: Mark Smith <[email-masked]>
Date: Mon, 18 Jan 2010 09:40:23 +1030

Hi Ole,

On Sun, 17 Jan 2010 22:02:25 +0100

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

---

From: Ralph Droms <[email-masked]>
Date: Sun, 17 Jan 2010 13:03:38 -0500

OK, now I'm clear on the terminology.  Thanks.

In your modified example, where the Office/Home routers are all  
connected to one LAN, there appear to be two different modes of  
operation for the routers: the CPE routers, getting prefixes from  
different ISPs, should ignore each others RAs and each should  
advertise the prefix it receives from its ISP on the root LAN.  The  
Office/Home routers, on the other hand, should listen to each others  
RAs and only one of those routers should advertise a prefix on the LAN  
they are all attached to.  Assuming all these routers are "plug-and- 
play", I don't see how they identify their location in the network and  
how they determine their appropriate mode of operation.

Similarly, how do the CPE routers identify themselves as such and  
determine they should elect a single "ULA authority" that generates  
and advertises a site ULA?

- Ralph

On Jan 14, 2010, at 1:39 PM 1/14/10, Fred Baker wrote:

> To me, a LAN is an instance of some lower layer networking  
> technology, such as an Ethernet or a WiFi; where a lawyer might have  
> defined it as a network that doesn't cross a legal boundary (for  
> which reason we don't call Frame Relay or ATM networks "LANs" but  
> rather "WANs"), RFC 872 defines it as
>
> A subnet is a set of interfaces that are assigned IP addresses  
> within the same prefix and can communicate without the intervention  
> of an IP router; some are "broadcast" (all of the interfaces can  
> talk with each other) and some are non-broadcast (they use the same  
> lower layer network but may not all have direct connectivity to each  
> other). The first use of the term in the RFC series is in RFC 61,  
> and is used synonymously with "subnetwork" in many RFCs prior to RFC  
> 1000. The term as we use it today, to refer to hierarchical  
> structure within a site prefix, probably derives from IEN 82 (1979),  
> which describes the MIT LCS Net Address Format, and in so doing  
> describes having "subnets" within the MIT campus that were not  
> separately advertised to the ARPANET, but advertised as a single  
> block network. It is commented on in a way more like a definition in  
> RFCs 891 and 898; 898 reports that
>
> 940, and 950, and it finally got defined in a form we would  
> recognize today in RFCs 1122, 1123, and 1812.
>
>> care must be taken to generate one ULA for the site and to keep  
>> that ULA consistent (as much as possible) over time.
>
> I think the CPE Router Design Team agrees with that statement.  
> They're asking whether 6man agrees with it.
>
>> - the CPE RTRs and the Office RTRs all receive RAs on the root  
>> link; they each
> throw a ringer in here; the even numbered subnets are discovered to  
> be WiFi using the same SSID, so that the picture really looks like:
>
>
>            /                   /
>            |                   |
>            |prefix:2 +------+  |
>            +---------|Office|  |
>            |         |RTR 1 +--+                 --
>            |         +---+--+  |  +-------+     /
> You note that the same LAN now has three prefixes on it - and not  
> just three, but three subnets of the common ULA, three subnets of  
> ISP#1's prefix, and three subnets of ISP#2's prefix. I submit that  
> this might just possibly be overkill, but there is no way apart from  
> of technology as it exists today. However, OR#1, OR#2, and HR can  
> hear each other asserting RAs on it, and can sort it out among  
> themselves.
>
>
>> In this case, CPE RTR ISP 1 acts as a DHCP-PD server for  
>> ISP1:0::/64 and ULA:0::/64 and CPE RTR ISP 2 acts as a DHCP-PD  
>> server for ISP2:0::/64.  The Office RTRs will receive delegated  
>> prefixes from both CPE RTRs and configure each of those  
>> "downstream" links with, e.g., ISP1:2::/64, ISP2:2::/64 and ULA: 
>> interaction with multiple DHCP-PD servers, so this scenario needs  
>> some extensions to RFC 3633.
>>
>> the CPE RTRs have to elect a ULA source and have a mechanism for  
>> ULA persistence in case the ULA source fails.  I suppose multiple  
>> ULAs in the site network would avoid the election and persistence  
>> issues at the cost of extra prefixes and complexity?
>>
>> playing and which configuration mechanism to use.  There also may  
>> be a need to exchange routing/forwarding information about the  
>> routers.
>
> Understood. I submit that we have enough mechanism to achieve that  
> if we use it creatively.
>
>> - Ralph
>>
>>> get prefixes delegated to them by those ISPs. In addition, to  
>>> cover the case in which one has no connectivity to either ISP (and  
>>> other using the other ISP or some such thing, you want an IP  
>>> subnet from each of those prefixes, and you want all of the  
>>> routers on the LAN in each subnet, with the possible exception of  
>>> the two ISP-facing routers being in each other's delegated prefixes.
>>>

---

From: Brian Haberman <[email-masked]>
Date: Mon, 18 Jan 2010 06:26:48 -0500

Ole,

On 1/17/10 4:02 PM, Ole Troan wrote:
>> 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).

Correct.  There is a lot of work to be done to solve this problem.  And
I don't see that work being taken up in the IETF with enough interest to
solve the problem anytime in the near future.

Regards,
Brian

> 
> cheers, Ole
> 
> 
>> 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... 
>>>>> 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
>>>> 
>>>> [email-masked] Administrative Requests:
>>>> https://www.ietf.org/mailman/listinfo/ipv6 
>> [email-masked] Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6

---

From: Thomas Narten <[email-masked]>
Date: Tue, 19 Jan 2010 14:21:05 -0500

Seems to me, that there is a fairly big problem here for which a
solution would be useful, namely, "zeroconf" of small sites (like home
networks). This involves a combination of:

1) It might be useful to generate a ULA automatically, without the
   user having to be involved. But, you only want one ULA per site,
   which means you need a protocol/practice that handles multiple
   routers at the site that think *they* should generate it if no one
   else does. And maybe a user wants to disable the use of ULAs. So
   you also need a mechanism for saying "don't automatically generate
   a ULA on my network"

2) small sites may well have more than one ISP connection, so you have
   the problem of automatically (?) identifying the site
   boundaries. (Again, presumably, you don't want grandma to be
   configuring this stuff, it needs to be automatic.)

3) There may well be more than on link (e.g, ethernet) present, so you
   have to subdivide any prefix for the site into individual subnets
   and distribute those (sub)prefixes to the appropriate routers. This
   is true whether you are using ULAs, global addresses or both. You
   also presumably want all the links to be assigned the same subnet
   number (for simplicity).

The IETF has never solved the above problem. Yet, if we just leave the
problem to individual vendors, I suspect we will end up with a mess.

> - are these requirements violating any RFC?

no. But this is the sort of thing that I would think is out of scope
for an IETF document to even say, unless it was targeted specifically
at the above problem. So, even though no RFC forbids it, doesn't mean
we recommend it either.

> - as this behaviour is not covered in existing IPv6 RFCs are they
>     clear enough for implementors to implement?

Clear, perhaps. But I'm not sure how much it really helps...
    
> - are these requirements sufficient to solve the whole problem?

Not a chance.

> - is this a problem which should be solved?

I tend to think that there is work here to be done. And better in the
IETF where a more holistic approach can be taken. But it is a hard
problem and I'm not sure we'd be successful... And we've done zeroconf
work before, without really producing a result.

>  behavour as specified in RFC4861?

Won't come close to solving your problem and I suspect you will find
that the above doesn't help a whole lot...

Thomas

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 19 Jan 2010 17:19:49 -0800

> Sent: Sunday, January 17, 2010 1:02 PM
> To: Brian Haberman
> Cc: [email-masked]; Fred Baker
> > 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.

Is there existing text (or assumptions?) that avoids a similar problem with
wired and wireless support on a *single* CE router and a computer (e.g.,
laptop)?

-d

> 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).
> 
> cheers,
> Ole
> 
> 
> > 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 
> 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.
> >>> 
> >>> Administrative Requests:

---

From: "Ranjith ......knowing peking" <[email-masked]>
Date: Wed, 20 Jan 2010 02:22:28 +0000

Most of the current implementations of ULA does not support automatic
generation of the global IDs corresponding to the ULAs. Users have to
generate the global id by using some external software (using the interface
id and current NTP time on the router). The User will have to do a lot to
generate and configure an ULA address, which he may tend to avoid.

Besides this, Once a global id is generated, filters should be added at the
site boundaries.
As Site is ambiguous, i feel manual configuration is required for supporting
ULA based network.

>                                                 router is advertising a
ULA prefix, the device MUST be configurable to
>                                                 ULA prefix.   MUST

I think the above will not help, as we are trying to restrict one site to
one ULA. It may not be case always.

On Tue, Jan 19, 2010 at 7:21 PM, Thomas Narten <[email-masked]> wrote:

> >                                                 router is advertising a
> ULA prefix, the device MUST be configurable to
> >                                                 automatically use this

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Jan 2010 15:51:21 +1300

> generate and configure an ULA address, which he may tend to avoid.

It seems to me trivial for a CPE router to do this (after a factory reset,
for example). We just need to specify it as a requirement.

> As Site is ambiguous, i feel manual configuration is required for supporting

The filter is on the WAN side. That also seems trivial to automate, since the
CPE knows where its WAN interface is.

The only tricky bit that I can see is avoiding multiple ULAs if there's more than
one CPE router. But that is a nice-to-have; there isn't really any harm in
having more than one ULA prefix configured.

    Brian

> ------------------------------------------------------------------------
>

---

From: Thomas Narten <[email-masked]>
Date: Wed, 20 Jan 2010 09:01:34 -0500

"Dan Wing" <[email-masked]> writes:

> wired and wireless support on a *single* CE router and a computer (e.g.,

No. Hence, my other note talking about the larger problem, of which
the above is just one small piece.

Today, there is no guidance/best practice describing how to use ULAs
in a network, other than to manually configure them.

Thomas

---

From: Mark Smith <[email-masked]>
Date: Thu, 21 Jan 2010 00:51:54 +1030

On Wed, 20 Jan 2010 09:01:34 -0500

> in a network, other than to manually configure them.

There is an Operational Guidelines section in the ULA RFC, which is
making recommendations e.g. sharing subnet IDs with global prefixes,
filtering of route announcements in BGP, Renumbering and Site Merging
etc.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jan 2010 09:43:28 +1300

> filtering of route announcements in BGP, Renumbering and Site Merging

There's also some material in RFC4864, but I think Thomas is correct
that some collected advice would be very useful.

    Brian

---

From: Brian Haberman <[email-masked]>
Date: Thu, 21 Jan 2010 09:54:38 -0500

> CPE knows where its WAN interface is.

As long as the filter is for *all* ULAs.  That way, if there are
multiple ULA prefixes in use on a network with multiple CPEs, you won't
have leakage of ULAs not generated on that specific CPE.

Regards,
Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Jan 2010 09:32:24 +1300

> have leakage of ULAs not generated on that specific CPE.

Correct, which is exactly what RFC4193 section 4.3 says:

   Site border routers and firewalls should be configured to not forward
   any packets with Local IPv6 source or destination addresses outside
   of the site, unless they have been explicitly configured with routing
   information about specific /48 or longer Local IPv6 prefixes.

     Brian C