Subject: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

From: Fred Baker <[email-masked]>
Date: Thu, 17 Mar 2011 11:12:46 -0700

The OSPF implementation I wrote at ACC in 1991-1993 required at most two configuration events: it had to be turned on, and subnets had to be given addresses. The same was true of RIP. And the same is true of each of the long list of competitors of yours that I noted a couple of days ago that consider placing a routing protocol in a CPE router a market requirement.

I submit that a zero-manual-configuration version can be built if the configuration is automated. That would not be a process this working group specifies, but as you note it is not rocket science. A competent engineer can figure out how to do it if it is deemed necessary. In the single subnet case, it simply means defaulting to a well-defined configuration; in the multi-subnet case, it requires implementation of DHCP or something like it to allocate /64s in the network.

I really don't think this conversation is going anywhere. Permit me to be uncharacteristically blunt while wearing my working group chair hat. 

Apple has designed a model for the residential network that assumes one /64 subnet in the home. This shows up in mDNS, which uses a link-scope multicast address as opposed to a site-scope multicast address, in your vehemence against incorporating a routing protocol in the CPE requirements, and in other places. It is as close as I can imagine to an Apple corporate position, something we try to avoid in the IETF. 

Tom Herbst has pointed out a need to route between a residential HAN and the remainder of the residential network due to differences between the LAN technologies. I have pointed out, months ago, use cases in which it is useful to have separate networks for security reasons (his and her corporate offices with corporate-specified security requirements) and separating the A/V bandwidth from other LAN usage in the home. I pointed out the other day that the use of routing in the home is far from a Cisco-corporate position - every residential CPE vendor I could quickly verify, with two exceptions (yours and another device that described itself as a "modem"), implements routing - at least RIP and in some cases OSPF - in their devices.

I will not rule that you're out of order here - if you can justify your position, the working group is listening. But I will warn you that you need to think about your passion a little more carefully. 

What we can do, and perhaps should do, is RECOMMEND that "IF a vendor chooses to implement a routing protocol in a CPE device, it SHOULD implement RIPng as described in RFC 2080, and MAY implement other protocols". But the preponderance of the evidence, in use cases, in discussion brought to the working group, and in surveyed equipment in the field, suggests that routing is done in the home in today's IPv4 networks, and something we can provide useful guidance on in residential/SOHO IPv6 networks. 

On Mar 17, 2011, at 10:11 AM, james woodyatt wrote:
> On Mar 17, 2011, at 09:31 , Ole Troan wrote:
>> 
>> there are multiple proposals for zero configuration routing. as far as I see there is no reason why we couldn't design a self configuring network at layer 3.
> 
> RIPng is not zero-configuration.  Neither is OSPF.  Searching the Internet draft archives, I find this abandoned draft from over ten years ago, which is an example of the sort of proposal I'm expecting to see:
> 
>  <http://tools.ietf.org/html/draft-akinlar-zeroconf-zrip>
> 
> That draft was Informational and never updated.  I can't find any other references to zero-configuration routing anywhere in the Internet draft archives or the RFC series.  If there are "multiple" proposals for zero-configuration residential network routing protocols, then I'd like to see them now, please.

---

From: Fred Baker <[email-masked]>
Date: Thu, 17 Mar 2011 11:35:34 -0700

On Mar 17, 2011, at 11:12 AM, Fred Baker wrote:
> Apple has designed a model for the residential network that assumes one /64 subnet in the home. 

In my note, I should have also pointed out that this is contrary to both RFC 3177 and its successor. The IETF has recommended to the operational community that - due to the use cases I mentioned - edge networks SHOULD be given prefixes that facilitate internal routing among an adequate number of subnets. 

In my home network, I could get away with a /63 - I have two subnets at the moment, my office and "everything else". However, if one presumes his and her offices, a separate A/V network from the main LAN (in my home, the wired backbone has 802.11 APs on it; one could also argue for routing between the wired and wireless networks), and routing into the HAN, the fingers on one hand are quickly exhausted. This and a personal preference for nibble boundaries is behind the suggestion I have made for residential networks, which is a /60 prefix (16 potential subnets) to the home. More generally, I would expect a provider to offer /60, /56, /52, and /48 prefixes to its customers as part of a suite of services at varying price points. The one that the IETF has uniformly recommended against is /64.

---

From: james woodyatt <[email-masked]>
Date: Thu, 17 Mar 2011 11:51:07 -0700

On Mar 17, 2011, at 11:12 AM, Fred Baker wrote:
> 
> I really don't think this conversation is going anywhere.

I'm sure I've made my position clear, and I seem to have persuaded no one that, if a routing protocol is to be recommended by this draft, then it MUST be a zero-configuration routing protocol.  I will now quit my campaign, and leave the discussion of this draft to proceed without further contribution from me.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Fred Baker <[email-masked]>
Date: Thu, 17 Mar 2011 12:47:04 -0700

> I'm sure I've made my position clear, and I seem to have persuaded no one that, if a routing protocol is to be recommended by this draft, then it MUST be a zero-configuration routing protocol.  I w…

Ack, and in residential networks in which (to pick one example) RIPng is in use and there is exactly one LAN, that shouldn't be a problem. What it means is:

 - deriving the LAN Subnet prefix from the RFC 3633 IA_PD
 - using the timing specifications (30 second inter-update interval, 180 second dead interval) from RFC 2080
 - periodically announcing a default route (2000::/3, which would be my thought, or ::/0).

In a network in which multiple LANs are present, and therefore multiple subnets, there must be a means to assign subnets from the IA_PD. One obvious approach is manual configuration; another requires a DHCP implementation that asks the ISP-facing router for a /64 for each of the other subnets. There are probably other approaches as well. The recommendation of an approach would be the province of another working group; we can ask either 6man or rtgwg for help with that.

<aside>

I find myself reading through several sections of RFC 2080, and having some thoughts. The requirement, for example, is that each prefix that is going to be advertised be advertised every <inter-update interval>; the requirement is not that they all be announced in a burst. I have had the joy of maintaining RIP code that operated literally as specified ("Every 30 seconds, the RIPng process is awakened to send an unsolicited Response message, containing the complete routing table (see section 2.6 on Split Horizon), to every neighboring router."). In a network with a large number of routes, that's actually a profoundly bad idea. What you want to do is emit individual unsolicited Response messages roughly evenly spread in time (if I am putting 70 RTEs in an announcement and have a network with 2100 routes, I might emit a single unsolicited response message containing 70 prefixes every second). You want to emit a triggered update when you yourself lose an interface (poison all routes you had using the interface, and yes, do that in a burst) and when you receive an update that changes your own route table. When an interface comes up, you want to emit an all-routers multicast request for routes, and you emit a burst response to the unicast address when you receive such a request.

I also don't really recommend poison reverse as the default way to implement split horizon. You want to do a poison reverse on a triggered update when a route is lost, and repeat that during announcements in the hold-down period, but after that it's a waste of bandwidth and CPU cycles. In normal operation, send the live routes.

But then, what do I know?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 17 Mar 2011 21:17:45 +0100 (CET)

On Thu, 17 Mar 2011, Fred Baker wrote:

> In a network with a large number of routes, that's actually a profoundly 
> bad idea.

Isn't there already wide consensus in the business that using RIP in large 
networks is a profoundly bad idea?

But still, aren't we talking about a home where most ISPs will deply /56 
meaning 256 subnets, which even a current typical CPE hardware platform 
will handle just fine using RIP?

Your concern about sending all the reports at once is still valid though.

I would of course prefer OSPF but I guess it's more complex to implement?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Fred Baker <[email-masked]>
Date: Thu, 17 Mar 2011 13:30:00 -0700

On Mar 17, 2011, at 1:17 PM, Mikael Abrahamsson wrote:

>> In a network with a large number of routes, that's actually a profoundly bad idea.
> 
> Isn't there already wide consensus in the business that using RIP in large networks is a profoundly bad idea?

That is a hard-won bit of wisdom. I have had some customers with O(5000) routes in a RIP network. Guess why I think about such things.

> But still, aren't we talking about a home where most ISPs will deply /56 meaning 256 subnets, which even a current typical CPE hardware platform will handle just fine using RIP?

Probably. And as I say, in a typical residential network I would be surprised it if sent more than one announcement every 30 seconds in any case.

> I would of course prefer OSPF but I guess it's more complex to implement?

OSPF could be described as "more complex".

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 17 Mar 2011 13:34:31 -0700

> OSPF could be described as "more complex".

I think RIPng is a better idea than OSPFv3 in the home just because i
fear that the OSFPv3 routes/hellos/whatever might leak into the SP and
cause mischief.  It is must less likely that the SP is running RIPng
and therefore less mischief to happen.

I know there are 1,001 safeguards to prevent this home-to-SP IGP
mischief, but sometimes stuff happens ...

Cameron

---

From: Mark Smith <[email-masked]>
Date: Fri, 18 Mar 2011 07:10:41 +1030

On Thu, 17 Mar 2011 12:47:04 -0700
Fred Baker <[email-masked]> wrote:

> I find myself reading through several sections of RFC 2080, and having some thoughts. The requirement, for example, is that each prefix that is going to be advertised be advertised every <inter-update interval>; the requirement is not that they all be announced in a burst. I have had the joy of maintaining RIP code that operated literally as specified ("Every 30 seconds, the RIPng process is awakened to send an unsolicited Response message, containing the complete routing table (see section 2.6 on Split Horizon), to every neighboring router."). In a network with a large number of routes, that's actually a profoundly bad idea. What you want to do is emit individual unsolicited Response messages roughly evenly spread in time (if I am putting 70 RTEs in an announcement and have a network with 2100 routes, I might emit a single unsolicited response message containing 70 prefixes every second). You want to emit a triggered update when you yourself lose an interface (poison all r
 ou
>  tes you had using the interface, and yes, do that in a burst) and when you receive an update that changes your own route table. When an interface comes up, you want to emit an all-routers multicast request for routes, and you emit a burst response to the unicast address when you receive such a request.
> 

I know that a single area OSPF configuration is simple,
zero-configuration with a basic initial and non-situation
specific configuration, handles the above scenario better, isn't CPU or
memory intensive anymore due to the effects of Moore's law unless it is
handling 1000s (if not 10s of 1000s) of routes, even for residential
CPE. I'd much prefer to see OSPF replace RIP as the chosen low-end
routing protocol in this day and age, in the least for it's much lower
convergence times.

I think the definition of zero-configuration for a routing protocol
is that it can determine or select necessary initial valid parameters
automatically (e.g. router-id, interface metrics), will discover
neighbors automatically and then trade routing information with them
without operator intervention, with a non-situation specific initial
bootstrap configuration. So pretty much all IGPs qualify, where as BGP
doesn't because it doesn't do automated neighbor discovery for good
reasons.

Regards,
Mark.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 17 Mar 2011 15:45:41 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Cameron Byrne
Sent: Thursday, March 17, 2011 4:35 PM
To: Fred Baker (fred)
Cc: IPv6 Ops WG
Subject: Re: [v6ops] I-D
Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

>and therefore less mischief to happen.

If OSPFv3 is used with the ULA prefix in the home any ULA sourced packet
will be blocked from heading out the WAN of the CE Router.  If OSPFv3
uses the IPv6 link-local address, the CE router has at least two
different link-local domains on the WAN and a LAN interface.   IPv6
traffic will not cross link-local domain.  

Hemant

---

From: Michael Newbery <[email-masked]>
Date: Fri, 18 Mar 2011 09:49:45 +1300

> In a network in which multiple LANs are present, and therefore multiple subnets, there must be a means to assign subnets from the IA_PD. One obvious approach is manual configuration; another requir…

The discussion must be seen in the context of the device. This is a residential gateway, and one that is owned and controlled by the customer, not the service provider. It therefor needs to cater to an audience that, in the vast majority of cases, wants to just plug it in and have it work. Zeroconf is an ideal, but a little bit of simple configuration should not be an issue.

From the point of view of the service provider, it's a totally untrusted element. Accordingly, except in extraordinary circumstances (i.e., where the SP does elect to trust its customer) the SP won't be listening to any routing advertisements. The SP assigned a prefix. It will send all traffic within that prefix to the RG. It really doesn't care if some subnet of that network is unreachable---that's the customer's problem.

On the LAN, the RG owns the default route. Absent mutlihoming it simply needs to tell the LAN that the WAN is/isn't there. It doesn't need to run an IGP to do this, RA is fine.

While it is arguable whether most LANs need to run an IGP at all, nevertheless, SOME do, so this is a legitimate scenario that must be accommodated.

Even so, the head router doesn't have to be the RG. The LAN, running an IGP, can still find the default-route from the RG which doesn't need to run an IGP. However, that attitude seems to me to be unnecessarily pure. The RG has to be a router after all, so having it run an IGP on the LAN seems a sensible thing to do.

Based on this analysis, I would advocate:
* The router MAY run an IGP
* If the router runs an IGP, it MUST support RIPng; it MAY support other IGPs
* If the router runs an IGP,  it MUST be disabled by default

I think a zeroconf IGP would be ideal, but there doesn't seem to be one at the moment, so we can't specify one.

The consumer must be able to take the RG out of the box, plug it in and have it work. Those who run a subnetted LAN, will have to do some additional configuration, but if they don's run a subnet, then they don't need to configure the IGP in the router, not even to turn it off.

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 17 Mar 2011 13:51:38 -0700

> and therefore less mischief to happen.

having done a class or two in which virtual topologies were constructed
on top of a common broadcoast domain by amatuers, I think the best way
by far to prevent leakage or interference between default configurations
and non-default ones is with a shared secret.

> mischief, but sometimes stuff happens ...

indeed.

> Cameron
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 17 Mar 2011 13:55:35 -0700

Regarding scaling, there is another way to do dynamic
routing when traditional proactive routing protocols
like OSPFv3 and RIPng cannot be used. For example, if
the CEs and BRs can be represented as neighbors on a
virtual NBMA link, then ICMP redirection can be used.

This would be classified as an on-demand (instead of
proactive) dynamic routing protocol, and so does not
need to hold non-essential routes in the RIB.

I have specified a way to do this for ISATAP in the
latest VET spec (draft-templin-intarea-vet) but the
same method can be applied to other mainfestations
of virtual NBMA links as well.

Thanks - Fred
[email-masked]

---

From: Michael Newbery <[email-masked]>
Date: Fri, 18 Mar 2011 10:00:12 +1300

> mischief, but sometimes stuff happens ...

The RG is untrusted, as far as the SP is concerned. Generally, a SP would be irresponsible if it listened (and propagated) routing information from the RG.

While I'm tempted to suggest that the draft should specify that the router MUST NOT send routing information on the WAN interface, given that the SP doesn't trust the RG, that's not actually very helpful. The responsibility for ignoring the RG rests with the SP, and after all there may be situations where the SP can and does trust the RG and hence can accept route updates from it.

---

From: Fred Baker <[email-masked]>
Date: Thu, 17 Mar 2011 14:09:52 -0700

Really? How does the router emitting the ICMP Redirect learn where routes should be directed to? How does it compare them?

---

From: Mark Smith <[email-masked]>
Date: Fri, 18 Mar 2011 07:42:08 +1030

On Fri, 18 Mar 2011 10:00:12 +1300

> The RG is untrusted, as far as the SP is concerned. Generally, a SP would be irresponsible if it listened (and propagated) routing information from the RG.

And I'd be willing to call the SP's operators incompetent if they
activate a misconfiguration like this - these aren't defaults they have
to remember to turn off.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 17 Mar 2011 22:16:53 +0100 (CET)

> virtual NBMA link, then ICMP redirection can be used.

I don't like ICMP redirects to be used for this. I have bad experience 
with them, and they're used on demand meaning if demand goes up, you get a 
lot more of them.

It's better to have the router know ahead of time where things should go 
and do it right from the beginning. I'm so against redirects I prefer to 
turn them off and have suboptimal routing all the time instead.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 17 Mar 2011 14:29:13 -0700

Hi Fred,

What I mean to say is that when a host on the LAN
side of CE 'A' sends packets to a host on the LAN
side of CE 'B', 'A' has to figure out what to do
with them since it all it has in its routing table
is a default route.

So, 'A' bounces the initial packets off its default
router 'C' which forwards them to 'B' but also
returns redirection messages to 'A'.

'C' can know about 'B' if it has full topology
information, but it is possible that 'C' also has
only partial topology information and has to default
route the initial packets through some higher level
gateway 'D'. 'D' can then forward the packets on
towards 'B', and can return redirection messages
to 'C', then 'C' can proxy the redirection messages
back to 'A'.

So, there can be a hierarchy of proxying gateways
in the operator's network, where each higher layer
in the hierarchy has more topology information than
the layer below it. I'm not quite asking for the same
thing as a full-up ND_Proxy, however, since all I'm
asking for is proxying of redirection messages.

Was this informational or obfuscational?

Thanks - Fred

> From: Fred Baker [mailto:[email-masked]] 
> Sent: Thursday, March 17, 2011 2:10 PM
> To: Templin, Fred L
> Cc: Hemant Singh (shemant); Cameron Byrne; IPv6 Ops WG
> Subject: Re: [v6ops] I-D 
> Really? How does the router emitting the ICMP Redirect learn 
> where routes should be directed to? How does it compare them?
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 17 Mar 2011 14:51:11 -0700

Hi Mikael, 

> From: Mikael Abrahamsson [mailto:[email-masked]] 
> Sent: Thursday, March 17, 2011 2:17 PM
> To: Templin, Fred L
> Cc: Hemant Singh (shemant); Cameron Byrne; Fred Baker (fred); 
> IPv6 Ops WG
> Subject: Re: [v6ops] I-D 
> with them,

I can understand "once bitten, twice shy", but I'm not
talking about plain-old redirects here. I have come up
with a two-way redirection scheme that addresses the
raft of issues inherent in the classical one-way scheme
that is published in the ND specs. I encourage you to
keep an open mind in spite of your bad past experiences.

> and they're used on demand meaning if demand goes 
> up, you get a 
> lot more of them.

Well, rate limiting was designed to address this issue.
We don't want to have a redirection event on each and
every data packet. As long as one or a few redirection
messages eventually make it back the route optimization
will still work. 

> and do it right from the beginning.

I don't disagree, but full topology can be difficult
to achieve when there are tens of thousands of routes
and routers or more.

> I'm so against redirects 
> I prefer to 

Well, suboptimal routing is only part of the issue.
The other part is the congestion in the default routers
that would groan under the strain if they couldn't
offload most of the traffic.

Thanks - Fred

---

From: Fred Baker <[email-masked]>
Date: Thu, 17 Mar 2011 15:02:53 -0700

> with them since it all it has in its routing table

In any context where routing comes up, there is more than one LAN in the local area, and the question is how to get a datagram from one to the other. Consider this simplistic case:

                        ISP
                         |
                      +--+---+
                      | CPE  |
                      |Router|
                      +--+---+
           ------+-------+----------------+-----
              +--+--+                 +---+--+
              |Alice|                 |Router|
              +-----+                 +--+---+
                                ----+----+--------
                                  +-+-+
                                  |Bob|
                                  +---+

Alice wants to send a datagram to Bob, and because she got her RA from the CPE, considers the CPE her default gateway. So sends the datagram to Bob's address at the IP layer, and to the CPE's address at the link layer.

If you are expecting the CPE to respond with a redirect to the other router in the picture, the CPE has to know that the other router is a router and has a LAN behind it, and specifically the LAN that Bob's subnet is on. More generally, in a home that has them all, one could readily imagine

                      ISP
                       |
                    +--+---+
                    | CPE  |
                    |Router|
                    +---+--+   Home backbone LAN
      -----+----------+-+--------+----------+---
       +---+--+   +---+--+   +---+--+   +---+--+
       |His   |   |Her   |   |A/V   |   |HAN   |
       |Office|   |Office|   |LAN   |   |Router|
       |Router|   |Router|   |Router|   +--+---+
       +---+--+   +---+--+   +---+--+      |
    -------+---  -----+---  -----+---  ----+----

If "Alice" is in "Her Office" and "Bob" is in "His Office", how does Alice's router know where the default route should point to? What is its "default gateway"?

I understand your point that if you have a trivially simple network, with one router and everything attached to it, it knows what you're doing. Predicating everything on that simplistic picture is, in my experience, naive.

---

From: Michael Newbery <[email-masked]>
Date: Fri, 18 Mar 2011 11:56:37 +1300

> In any context where routing comes up, there is more than one LAN in the local area, and the question is how to get a datagram from one to the other. Consider this simplistic case:

Good point. So, for any subnetted LAN topology OTHER than the following (for which RAs suffice), an IGP in the CPE router is necessary.

                       ISP
                        |
                     +--+---+
                     | CPE  |
                     |Router|
                     +--+---+
                     +--+---+
                     |Router|
                     +--+---+

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 17 Mar 2011 16:20:41 -0700

Hi Fred, 

> Sent: Thursday, March 17, 2011 3:03 PM
> To: Templin, Fred L
> In any context where routing comes up, there is more than one 
> LAN in the local area, and the question is how to get a 
> datagram from one to the other. Consider this simplistic case:
> 
>                         ISP
>                          |
>                       +--+---+
>                       | CPE  |
>                       |Router|
>                       +--+---+
> Alice wants to send a datagram to Bob, and because she got 
> her RA from the CPE, considers the CPE her default gateway. 
> So sends the datagram to Bob's address at the IP layer, and 
> to the CPE's address at the link layer.

Yes, this is perhaps too simplistic a diagram to give the 
full flavor for what I had in mind.

> If you are expecting the CPE to respond with a redirect to 
> the other router in the picture, the CPE has to know that the 
> other router is a router and has a LAN behind it, and 
> specifically the LAN that Bob's subnet is on. More generally, 
> in a home that has them all, one could readily imagine
> 
>                       ISP
>                        |
>                     +--+---+
>                     | CPE  |
>                     |Router|
> If "Alice" is in "Her Office" and "Bob" is in "His Office", 
> how does Alice's router know where the default route should 
> point to? What is its "default gateway"?

Yes, this is a better diagram for a more general discussion.
Looking at the "Home backbone LAN" in the figure, what I'm
expecting is two different classes of routers. Consider the
CPE Router as an "advertising" router and consider the others
(including Bob's and Alice's) as "non-advertising" routers. I
am asking that the non-advertising routers behave as if they
were hosts on the Home backbone LAN from the standpoint of
Router Discovery and thereby configure a default route that
points to the advertising router.
 
> I understand your point that if you have a trivially simple 
> network, with one router and everything attached to it, it 
> knows what you're doing. Predicating everything on that 
> simplistic picture is, in my experience, naive.

Right, but I'm not thinking in terms of just the simplistic
picture. Take your general diagram above and replicate it,
say, 10K times to represent 10K home network customers in
a modest ISP deployment. Now put a PE router in the ISP
network that acts as a default router for all of the CEs:                       
                       
                    +--+---+
                    |  PE  |
                    |Router|
                    +---+--+   ISP backbone
      -----+----------+-+----------+------------+---
       +---+--+   +---+--+     +---+--+     +---+--+
       | CE 1 |   | CE 2 |     | CE i |     |CE 10K|
       |Router|   |Router| ... |Router| ... |Router|
       +---+--+   +---+--+     +---+--+     +---+--+
     ------+---  -----+---    -----+---    -----+---
     Home LAN 1  Home LAN 2   Home LAN i   Home LAN 10k

and the paradigm works the same except that the PE
router has to keep track of 10K CE routers.

So, add more PE routers to balance the load:

            +---+--+           +---+--+     +---+--+
            |  PE  |           |  PE  |     |  PE  |
            |Router|  ISP      |Router|     |Router|
            +---+--+  B-Bone   +---+--+     +---+--+
      -----+----------+  ...  -----+--- ... ----+---
       +---+--+   +---+--+     +---+--+     +---+--+
       | CE 1 |   | CE 2 |     | CE i |     |CE 10K|
       |Router|   |Router| ... |Router| ... |Router|
       +---+--+   +---+--+     +---+--+     +---+--+
     ------+---  -----+---    -----+---    -----+---
     Home LAN 1  Home LAN 2   Home LAN i   Home LAN 10k

and it looks like the ISP backbone is segmented. But,
if the PE's talk to each other then they can act as
"bridges" to bridge the segments together:

            +---+--+           +---+--+     +---+--+
            | PE A | <-------> | PE B |<--> | PE C |
            |Router|  ISP      |Router|     |Router|
            +---+--+  B-Bone   +---+--+     +---+--+
      -----+----+-----+  ...  -----+--- ... ----+---
       +---+--+   +---+--+     +---+--+     +---+--+
       | CE 1 |   | CE 2 |     | CE i |     |CE 10K|
       |Router|   |Router| ... |Router| ... |Router|
       +---+--+   +---+--+     +---+--+     +---+--+
     ------+---  -----+---    -----+---    -----+---
     Home LAN 1  Home LAN 2   Home LAN i   Home LAN 10k

Or if you prefer the PEs could talk to some higher
layer gateway or gateways that have full topology
knowledge:

                          +---+---+
                          |Gateway|
                          |   G   |
                          +---+---+

            +---+--+           +---+--+     +---+--+
            | PE A |           | PE B |     | PE C |
            |Router|  ISP      |Router|     |Router|
            +---+--+  B-Bone   +---+--+     +---+--+
      -----+----+-----+  ...  -----+--- ... ----+---
       +---+--+   +---+--+     +---+--+     +---+--+
       | CE 1 |   | CE 2 |     | CE i |     |CE 10K|
       |Router|   |Router| ... |Router| ... |Router|
       +---+--+   +---+--+     +---+--+     +---+--+
     ------+---  -----+---    -----+---    -----+---
     Home LAN 1  Home LAN 2   Home LAN i   Home LAN 10k

So, in this kind of arrangement, if a host behind CE 1
has a packet to send to a host behind CE 10K, CE 1 first
forwards the packet to PE A as its default router, but
PE A does not have enough information to send a
redirection message back.

So, PE A has to "pay it forward" - it sends what I am
calling a "Predirect" message to Gateway G, which
looks at the destination address of the packet that
triggered the Predirect and then proxies the Predirect
through to PE C. PE C further proxies the Predirect
message on to CE 10K. Now CE 10K knows about CE 1, so
it sends a "Redirect" message back along its default
router chain, where it will be proxied by PE C, then
Gatway G, then PE A, and finally to CE 1. Now CE 1
knows about CE 10K, and there is route optimization.

Does this clarify?

Fred

---

From: Fred Baker <[email-masked]>
Date: Thu, 17 Mar 2011 16:23:19 -0700

So we have started designing yet another bellman-ford routing protocol...

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 17 Mar 2011 16:42:02 -0700

Hi Fred, 

> Sent: Thursday, March 17, 2011 4:23 PM
> To: Templin, Fred L

I wouldn't say that we have "started" to design another
protocol. What I have said already both here and in the
spec is all there is to it (honest), so that plus the
fact that we are using a minor backwards-compatible
extension to a standard mechanism means that we have
already finished more or less. Or, do you see some
next step necessary before I get to work on the code?

Thanks - Fred

---

From: Fred Baker <[email-masked]>
Date: Thu, 17 Mar 2011 16:45:53 -0700

In any event, in this context, maybe you want to start with requirements.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 17 Mar 2011 16:51:35 -0700

> Sent: Thursday, March 17, 2011 4:46 PM
> To: Templin, Fred L

Point well taken; thanks.

Fred

---

From: Fred Baker <[email-masked]>
Date: Thu, 17 Mar 2011 16:54:22 -0700

actually, in this topology, the two routers need to talk with each other. One or both will issue RAs on the backbone LAN; absent a routing exchange (regardless of protocol - something that communicates the information about what prefixes are where), there is no way for either to tell what's behind the other.

---

From: Thomas Herbst <[email-masked]>
Date: Thu, 17 Mar 2011 19:46:52 -0700

Though I thought you completely wrong-headed on this particular topic, I
do hope that you continue to be engaged and make contributions to other
sections of the document. There are too few people with CPE implementation
experience involved in working group.

tom

On 3/17/11 11:51 AM, "james woodyatt" <[email-masked]> wrote:

>I'm sure I've made my position clear, and I seem to have persuaded no one
>that, if a routing protocol is to be recommended by this draft, then it
>MUST be a zero-configuration routing protocol.  I will now quit my
>campaign, and leave the discussion of this draft to proceed without
>further contribution from me.
>
>
>--

---

From: Ole Troan <[email-masked]>
Date: Fri, 18 Mar 2011 10:29:29 +0100

James,

> I'm sure I've made my position clear, and I seem to have persuaded no one that, if a routing protocol is to be recommended by this draft, then it MUST be a zero-configuration routing protocol.  I w…

I think we agree that:
 - in todays home network a single router is sufficient for almost all known cases (this router may have 
   multiple links) and be extended with bridges
 - to support a "routed home", then a routing protocol is required, and this routing protocol MUST be zero
   configuration / self configured

so consider me persuaded. ;-)

I'm cautious about recommending a particular protocol at this stage. since I believe the routing protocol chosen is dependent on the mechanism used for prefix assignment.

cheers,
Ole

---

From: Daniel Roesen <[email-masked]>
Date: Fri, 18 Mar 2011 10:42:06 +0100

On Fri, Mar 18, 2011 at 10:29:29AM +0100, Ole Troan wrote:
>  - to support a "routed home", then a routing protocol is required

May I kindly repeat my question already posted in
http://www.ietf.org/mail-archive/web/v6ops/current/msg07906.html
which went without any reply:

What is the use-case of a full-blown IGP in a home network that a
DHCPv6-PD cascade cannot provide?

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

---

From: Ole Troan <[email-masked]>
Date: Fri, 18 Mar 2011 11:00:14 +0100

Daniel,

> DHCPv6-PD cascade cannot provide?

 - there is no guarantee that a customer plugs routers in the way you want them to.
   e.g. they may create loops, redundant paths and so on
 - DHCPv6 PD doesn't handle multi-homing very well. e.g. if you have two upstream CPEs then
   DHCPv6 will pick one of them to use as the DHCPv6 server, not getting a prefix from the second one

to turn the question around. assuming a zero-configuration routing protocol (really both RIP and OSPF are/can be made to be) what's the big deal about supporting one?

cheers,
Ole

---

From: Daniel Roesen <[email-masked]>
Date: Fri, 18 Mar 2011 11:25:11 +0100

>    e.g. they may create loops, redundant paths and so on

A DHCPv6-PD cascade would be inherently loop-free, wouldn't it?

My assumption here is that a router device has dedicated upstream ("WAN")
and downstream ("LAN") interfaces.

>  - DHCPv6 PD doesn't handle multi-homing very well. e.g. if you have
>    two upstream CPEs then DHCPv6 will pick one of them to use as the
>    DHCPv6 server, not getting a prefix from the second one

So your goal is zero-conf residential multi-ISP multi-homing? That's a
different requirement than just 'support a "routed home"'.

> to turn the question around. assuming a zero-configuration routing
> protocol (really both RIP and OSPF are/can be made to be) what's
> the big deal about supporting one?

Troubleshooting when things don't work perfectly. Think of a router
"gadget" injecting "defect" routes into the IGP, and things start to
randomly break for the whole home network.

Some (many?) service providers are actually supporting the CPE devices
they provide to the customer with their residential connection. I cannot
see how a typical residential ISP support org could even remotely
troubleshoot IGP-induced problems.

In my view, multi-ISP multihoming of residential networks is too big a
challenge to incorporate in the cpe-router-bis effort - it should be
a separate set of specification, starting with a requirements analysis.

Best regards,
Daniel

---

From: Ole Troan <[email-masked]>
Date: Fri, 18 Mar 2011 11:37:59 +0100

Daniel,

> A DHCPv6-PD cascade would be inherently loop-free, wouldn't it?

so my question was: how do you ensure that the customer understands graph theory? ;-)

> troubleshoot IGP-induced problems.

and you think a protocol that works only in certain topologies, has to be plugged in the correct way (with upstream and downstream interfaces), requiring a snooping function to inject "static" routes, with timers to maintain them. can't go wrong and is easy to maintain? at least with a link-state IGP every router would have a complete map of the network. not so with a bunch of static routes pointing in who knows what direction...

> a separate set of specification, starting with a requirements analysis.

OK, I agree with that. I'm arguing this more from a "homenet WG" point of view.
I'm in two minds if we need the bis document out quickly, or if we should rather focus on the 'bigger' use case. I assume that the basic IPV6 CE req document has bought us quite some time(?)

cheers,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 18 Mar 2011 09:03:05 -0700

Hi Fred,

Here is a start at a set of requirements; please send
comments.

Thanks - Fred

Background:
***********
CPE routers connect to ISP networks via their WAN-side
interfaces, and connect to one or more customer end site
networks on their LAN-side interfaces. In near-term
deployments, the WAN side is likely to be IPv4-only and
so a tunneling mechanism configuired over the ISP network
may be necessary to provide the CPE with IPv6 services
[6RD][ISATAP].

In such environments, it will be desirable for the CPE to
obtain a native IPv6 prefix from the ISP so that it can
sub-delegate the prefix to end site devices. However, the
ISP network may connect many orders of magnitude more CPE
routers than could be accommodated by a traditional
full-topology IPv6 IGP such as RIPng or OSPFv3.

Without such full-topology knowledge, CPE routers would be
obliged to forward their packets through ISP infrastructure
routers that do have full-topology knowledge. This can lead
to sub-optimal routes and traffic concentration on
performance-critical ISP routers. Hence, CPE routers require
a partial-topology dynamic routing protocol that can be
used in place of a traditional IGP.

Requirements:
*************
The partial-topology dynamic routing protocol must satisfy
the following requirements:

1) Off-load traffic from performance-critical ISP routers.
The mechanism must support intra-ISP routing between native
IPv6 prefixes without requiring sustained transit though an
ISP infrastructure router that would become a traffic
concentrator.

2) Support route optimization.
CPE routers must be able to tunnel their packets with
native IPv6 addresses directly to other CPE routers
without involving ISP routers as intermediary tunnel
endpoints.

3) Support multiple levels of hierarchy.
For scaling purposes, allow multiple levels of hierarchy
in which routers in higher levels have progressively more
topology knowledge than those in lower levels.

4) Do not circumvent IPv6 filtering.
The mechanism must not open an attack vector where IPv6
source address spoofing is enabled even when IPv4 source
address spoofing is disabled.

5) Do not open expose packets to loss due to black holes.
The tunnel ingress must have a way of knowing that the
tunnel egress will accept its encapsulated IPv6 packets.

6) Support IPv6 prefix mobility.
The mechanism must continue to work even if an IPv6
prefix moves from a first CPE router and re-attaches
itself to a second CPE router.

7) Also support the same mechanisms on the LAN side.
When the customer end site consists of an IPv4 network
with multiple IPv4 routers, links, etc., an IPv6
tunneling mechanism may be needed on the LAN side and
the same dynamic routing mechanisms employed on the
WAN side can also be used on the LAN side.

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 18 Mar 2011 09:23:14 -0700

> DHCPv6-PD cascade cannot provide?
.
the connection of a subnet with it's own stable ula or  unique prefix
assignment

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 18 Mar 2011 09:28:48 -0700

> different requirement than just 'support a "routed home"'.

I could imagine that but I don't see it as a goal. an igp by be
necessary but not sufficient for that, I don't see having more than one
device injecting default originate into an igp as a particularly good idea.

> troubleshoot IGP-induced problems.

the same applies to residential deployments that have double-nat in in
them today. e.g. two layer three devices cascaded off each other works
today, for some value of work.

> a separate set of specification, starting with a requirements analysis.

indeed

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 19 Mar 2011 08:29:49 +1300

> so my question was: how do you ensure that the customer understands graph theory? ;-)

In the late 1980s at CERN, I learnt the hard way that world-class physicists
don't understand graph theory, which is how we ended up with one of
the largest and ugliest bridged Ethernets in existence at that time.
Believe me that without the spanning tree (which is indeed zero-conf)
the packets would have been spinning in loops for ten years.

It's absolutely guaranteed that SOHO users will configure loops.

   Brian

---

From: Fred Baker <[email-masked]>
Date: Fri, 18 Mar 2011 13:08:36 -0700

> DHCPv6-PD cascade cannot provide?

</chair>

I believe that they solve different problems. DHCPv6-PD is a means of delegating prefixes; within a network, it is a means of delegating prefixes to routers on a LAN. An IGP is a means for routers that have prefixes delegated to the communicate routing information and the changing state of routing. They are complementary, not interchangeable.

Coming back to my graphic from yesterday

                     ISP
                      |
                   +--+---+
                   | CPE  |
                   |Router|

I'll note that in my home, the wireless goes everywhere and constitutes a backup path for any device in the home as well as a primary path for any device that has no other attachment. As I type, my computer is on the Cisco corporate network as a wired device and the wireless as a device in the home, to enable my telephone (which uses WiFi as one of its media) to change calendaring information with it. Insert a second wireless router instead of a wireless host, and it's a very big loop. Therefore, for sake of discussion, let's add "Looping LAN" to the picture:

                     ISP
                      |
                   +--+---+
                   | CPE  |
                   |Router|
                   +---+--+   Home backbone LAN
                       |
     -----+----------+-+--------+----------+---
          |          |          |          |
      +---+--+   +---+--+   +---+--+ | +---+--+
      |His   |   |Her   |   |A/V   +-+ |HAN   |
      |Office|   |Office|   |LAN   | +-+Router|
      |Router|   |Router|   |Router| | +--+---+
      +---+--+   +---+--+   +---+--+ |    |
   -------+---  -----+---  -----+--- | ---+----
                                     |
                              Looping|
                                LAN  |

The way I would expect DHCPv6-PD to work, if we used it to allocate /64s within the home, would be for my ISP to allocate a prefix (hopefully /60 or shorter) to the CPE Router, the CPE to delegate a /64 to each of its own LANs (as drawn, one) and announce an RA, and the other routers to infer addresses and prefix allocation in that prefix on relevant interfaces. They might then realize that they didn't have prefixes for their other interfaces and issue DHCPv6-PD requests to get them. There are two possible next steps - the CPE simply allocates in response to each request, meaning that if there is a loop somewhere each router on the relevant LAN starts announcing a separate prefix (not ideal, but not exactly *wrong* either), or by some means it prevents that from happening. 

If a default OSPF or IS-IS configuration existed in the home, most of the routers would quickly determine that they were on "stub LANs"; they would find that they were alone on their LANs and became the Designated Router with no backup. On the "Looping LAN", the two routers would determine that it was a "transit LAN" but had no prefix; one would be DR, one would be backup, and there would be no possibility of a host. One could imagine the Designated Router on each of those LANs realizing it needed a prefix and using DHCPv6 to ask for one. Voila, one /64 per LAN.

In any other case, one could also imagine the CPE Router rate-limiting its responses, perhaps at most one a second. If we presume that the various routers repeat their requests at some rate, perhaps every 3 seconds, it would take at most six requests in the worst case for the routers to obtain /64s for their LANs, an in the case of the Looping LAN, when one announced an RA, the other would hear it.

So, fine, we can use DHCPv6-PD to delegate prefixes to the LANs. We can't necessarily use it to specify routing, however, without making assumptions that might not be warranted. For example, if the "HAN Router" was the one that successfully allocated a prefix for the "Looping LAN" and subsequently failed, how would the "CPE Router" know that it could use the "A/V LAN Router"?

That's where an IGP comes in - as in any network. It communicates status among the routers and allows them to draw graphs. If something fails or is added/restored, it communicates the information.

I would be very careful about confusing DHCPv6-PD with routing. They are very different. We need a way to delegate prefixes, and yes, I just described two different zeroconf ways to delegate prefixes using DHCPv6-PD. We also need to be able to route. But delegation and routing are not the same thing.

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 18 Mar 2011 13:18:06 -0700

> It's absolutely guaranteed that SOHO users will configure loops.

they do in every residential ethernet network I've ever operated. 3000
students can install a hell of a lot of crap in 1 week of moving into
residence halls. As their provider we could protect our routing and l2
domain from theirs but the extent to which we can protect them from
themselves is limited.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 21 Mar 2011 14:37:18 -0700

Hi Lee,

Thanks for your thoughts, and see below: 

> From: Lee Howard [mailto:[email-masked]] 
> Sent: Monday, March 21, 2011 1:59 PM
> To: Templin, Fred L; 'Fred Baker'
> Cc: 'IPv6 Ops WG'
> Subject: RE: [v6ops] Dynamic routing requirements for IPv6 CPE routers
> 
> 
> 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of
> Templin,
> > Fred L
> > Sent: Friday, March 18, 2011 12:03 PM
> > To: Fred Baker
> > Cc: IPv6 Ops WG
> > Subject: [v6ops] Dynamic routing requirements for IPv6 CPE routers
> > 
> > Hi Fred,
> > 
> This may be true for sufficiently small values of "near term."
> This requirement may be overtaken by events if we need to 
> define a new protocol to meet the requirements below.

Well, the definition is already captured in the VET spec,
and it builds on the existing ICMPv6 Redirect message.
The same kind of approach can also be used for tunneling
over IPv6.

> Can you clarify the constraint?  Is it that routers can't handle
> millions of neighbors, or millions of routes, and is it a constraint
> of memory, CPU, or protocol?  I think I know what you mean,
> but I want to be sure.

It is all of the above, but most particularly the over-the-
wire control message overhead for conveying, e.g., routing
protocol link state information.

> Customer edge needs a default route pointing upstream.

Yes.

> If the
> router is multihomed, then I'm sure I don't understand the problem.

I'm not sure I understand this. If the customer edge
router is multihomed, it has multiple default routes
and has to select the correct one for outbound packets,
e.g., based on source address. Still, after selecting
a default route there may be a better next hop that can
be determined by the dynamic on-demand route discovery
approach I am describing.  

> Provider edge needs a prefix router pointing downstream.  Could
> be injected any number of ways; I don't understand what all the
> remaining requirements have to do with it.

The customer edge router trusts the provider edge router
to forward its outbound packets and to tell the truth
about more direct routes to other customer edge routers.
The approach I'm describing depends on such an arrangement.  

> Taking the above two together, you want to be able to 
> dynamically build tunnels to transport IPv6 traffic over IPv4,
> without having to go through a relay.  ?

Its not really about dynamically building tunnels; it
is about discovering neighboring tunnel endpoints on
a non-broadcast, multiple access (NBMA) tunnel virtual
link. It works exactly the same way as ICMPv6 Redirects,
except that both the ingress and egress tunnel neighbors
need to be made aware of the route optimization.

> i.e., you want to define a new tunneling protocol as a 
> transition mechanism?

Not defining a new tunneling protocol - just specifying
the operation of the Redirect function on existing tunnel
protocols.

Thanks - Fred

> Lee

---

From: "Lee Howard" <[email-masked]>
Date: Mon, 21 Mar 2011 16:59:01 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Templin,

> used in place of a traditional IGP.

Customer edge needs a default route pointing upstream.  If the

Lee

---

From: "Lee Howard" <[email-masked]>
Date: Mon, 21 Mar 2011 16:59:01 -0400

Templin,

Lee