Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here

From: Ole Troan <[email-masked]>
Date: Tue, 1 Feb 2011 13:21:16 +0100

Jack,

> Honestly, I want off the shelf multi vendor  CPEs that I can stack in any combination or order, they handle numbering by themselves, they agree on firewall rules by themselves, and they provide me an easy mDNS selectable interface for connecting to all the management interfaces. Knowing my customers, they want the same thing; plug it in somewhere and it should work (and they really wish if they plugged the DSL modem into a LAN port accidentally, that the router would just work).

+1.

that in my mind requires:
 - unicast and multicast routing in the home
 - "border detection". a router knows internal and external interfaces
 - service discovery of a wider scope than link-local
 - distribution of other configuration information
 - prefix and address assignment (e.g. zOSPF or similar)

pretty much see the proposed homenet WG charter proposal.

cheers,
Ole

---

From: Fred Baker <[email-masked]>
Date: Tue, 1 Feb 2011 15:03:28 +0000

On Jan 31, 2011, at 9:36 PM, Jack Bates wrote:

> On 1/31/2011 3:29 PM, Ole Troan wrote:
>> one where there is no administrative boundary between the customer
>> and the provider you mean? this solution should also handle the case
>> where the end user network is connected to multiple providers.
>> 
> 
> To be honest, there is no administrative boundary in zeroconf CPEs today. Boundaries only form when a customer starts to actually manage their CPE. My only issue is that the current model forces the ISP to do one of two things:
> 
> 1) Restrict all customers to a single routed CPE interfacing with the ISP (here's your /48, /56, etc but only one)
> 
> 2) Issue longer prefixes and more of them to the CPE in an on-demand scenario (okay, you've issued 6 /64 requests, and I'll answer those up to 20, then I say you're done).
> 
> The first is the better option of the 2, but it continues to restrict the provider/customer interface in ways that are not desirable.

I find this statement really surprising. It conflates allocation with routing.

It seems to me that if a downstream network had N>1 interfaces to a given upstream and got a prefix (/44, /63, whatever) from it, the upstream would normally consider that it could route the entire prefix to each of the N interfaces according to whatever rules it chose, and the downstream could allocate /64s within the prefix as it chose.  In other words, it would operate the same way that it would operate if the downstream had PI space with the exception that the upstream wouldn't advertise the more specific route - it would merely announce its own much-shorter prefix.

---

From: Jack Bates <[email-masked]>
Date: Tue, 01 Feb 2011 09:38:30 -0600

On 2/1/2011 9:03 AM, Fred Baker wrote:
> the upstream would normally consider that it could route the entire
> prefix to each of the N interfaces according to whatever rules it
> chose, and the downstream could allocate /64s within the prefix as it
> chose.  In other words, it would operate the same way that it would
> operate if the downstream had PI space with the exception that the
> upstream wouldn't advertise the more specific route - it would merely
> announce its own much-shorter prefix.

My problem with this, is that there's no guarantee that the N interfaces 
share any routing information between them. It's a generic home network.

What always gets me is that implementations I've seen treat DHCPv6-PD as 
individual prefixes without a concept of reserving space and issuing 
needed space out of it.

I have no problem routing a /48 to a customer CPE. The problem isn't the 
educated. The problem is the ability to configure a SP edge to allow any 
number of configurations in a home network and just allow it to work.

Yes, there's alternatives, such as CPE standards perhaps recognizing 
each other even on the wan and splitting address space. The whole 
mechanism could be done in a CPE, but whatever method is chose, it 
should be pushed forward and mandated as support for zeroconf. We are 
quickly on the way to returning to the original days of when buying a 
CPE required a lot of manual configuration, when IPv6 has the capability 
of doing so much more.

Jack

---

From: Mark Smith <[email-masked]>
Date: Wed, 2 Feb 2011 06:46:41 +1030

On Mon, 31 Jan 2011 16:30:16 -0600
Jack Bates <[email-masked]> wrote:

> 
> 
> On 1/31/2011 4:14 PM, Michael Newbery wrote:
> > +1. While a fully managed service is something that a customer may
> > wish to purchase, that's a whole different service to the normal ISP
> > case, and keeping a clean demarcation only enhances even a fully
> > managed service offering.
> 
> You've also broken a good portion of my customers if they left 
> everything plugged in as is and could upgrade their routers to IPv6 (or 
> I'll be issuing 2-8 /48's for a single customer, as it's not uncommon 
> for multiple routers to be connected into the ISP bridging modem, or 
> even a switch connected to the modem with a string of routers connected 
> to it)
> 
> We're not talking about changing the demarcation. We're talking about 
> the ability separate allocation to customer from delegation to a router. 
> More specifically, multiple routers, in an automated fashion. There's no 
> additional tracking concerns.
> 
> 1) Customer has 1 router and it has 1 or more delegations inside of an 
> allocation which can all be summaries as an aggregate.
> 
> 2) Customer has multiple routers and it has multiple delegations inside 
> of an allocation which can be summaries as a group of aggregates if you 
> need specific router information or as the entire allocation if you only 
> care about the specific customer.
> 

The issue with this second model is that a multihomed CPE or multiple
CPE  scenario isn't in scope for the simple CPE draft, and trying to
address it in the simple CPE draft at this time would only further
delay its publication. In the longer term, dynamic multihoming would be
useful, and may become far more popular. However, I think it is
important to soon have an RFC that describes the IPv6 equivalent of the
most commonly deployed IPv4 scenario today, which is the single CPE,
single homed scenario.

> I'm not saying that everyone will agree with the model. Yet, to not even 
> support the model? Is there another model you have for supporting this 
> without issuing longer prefixes which can lower the depth of the 
> customer network?
> 
> Jack
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Lee Howard" <[email-masked]>
Date: Tue, 1 Feb 2011 19:27:55 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jack Bates
> even a switch connected to the modem with a string of routers connected

That's not uncommon?  To me, that's unheard of in a " residential or
   small office router."

If the problem statement is, "We need to define behavior for a device 
that supports an arbitrary number of instances in an arbitrary topology 
with an arbitrary number of connections without requiring management
or configuration, and for less than $50USD," then we have scoped 
ourselves beyond the possible.

Issue multiple prefixes per customer, if you support multiple routers.  If
you don't like the prefix length, change it.  

Lee

---

From: Jack Bates <[email-masked]>
Date: Tue, 01 Feb 2011 19:12:18 -0600

> ourselves beyond the possible.
How have we scoped ourselves beyond the possible? You write the standard 
for the protocols. Vendors implement the protocols. Many vendors have 
shared code from chip manufacturers, so I don't really see an issue 
here. Provide the guidance for it to happen, they'll implement it. 
Nothing I've suggested will consume a lot of memory or flash (the major 
pricing points). More importantly, it's a matter of properly addressing 
the entire problem caused by shifting from IPv4 with NAPTv4 into IPv6 
with DHCPv6-PD.

> you don't like the prefix length, change it.

The problem is, the desired goal is to look at assigning a single /48 
per site, and being able to support that site. My original viewpoint on 
the problem was that the ISP layer can actually handle some of this 
versatility. Most of it could be developed as a CPE protocol to handle 
sharing of addressing even via the WAN interface. However, a protocol of 
that scope will require even more work on the part of the CPE. I was 
trying to develop a method that:

1) better utilizes the existing protocols

2) changes things closer to implementation level than the actual 
protocols themselves

3) defines logic and methodology which currently isn't documented or 
standardized.

4) focuses on what works best in CPE PD handling first, treating support 
at the ISP level as a secondary option, but not required (ie, a CPE 
plugged into another CPE should just work and needs to be addressed, but 
how a CPE treats assignments should also be supported at the ISP level 
as an option).

We cannot leave chained DHCPv6-PD issues unresolved. There needs to be a 
standard for that. Applying similar logic up to the ISP level is also 
prudent, for those ISPs which do which to offer such services to their 
customers and to insure interoperability. As it stands, IPv6 cpe routers 
are likely to only be interoperable in a single configuration:

ISP -> CPE -> HOST

This is a step back from what we support in IPv4.

Jack

---

From: james woodyatt <[email-masked]>
Date: Thu, 03 Feb 2011 08:15:28 -0800

On Jan 30, 2011, at 23:10, Joel Jaeggli wrote:
> 
> The operative thing I took away from it is you can't just bridge
> 802.15.4 to ethernet so if you want ot interconnect them you;r egoing to
> have to route.

Or use an application layer gateway.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 03 Feb 2011 08:17:00 -0800

> Or use an application layer gateway.

agree