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

From: Fred Baker <[email-masked]>
Date: Mon, 31 Jan 2011 06:54:01 +0000

Question for the assembled throng: What do people want to see happen in draft-wbeebee-v6ops-ipv6-cpe-router-bis?

Part of the outcome of IETF 79 was a discussion around Tom Herbst's draft regarding interactions with the Smart Grid's Home Area Network. This is something that is not mandatory in a next generation residential router, but I suspect will have utility. Comments to the list, please.

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 30 Jan 2011 23:10:06 -0800

On 1/30/11 10:54 PM, Fred Baker wrote:
> Question for the assembled throng: What do people want to see happen
> in draft-wbeebee-v6ops-ipv6-cpe-router-bis?
> 
> Part of the outcome of IETF 79 was a discussion around Tom Herbst's
> draft regarding interactions with the Smart Grid's Home Area Network.
> This is something that is not mandatory in a next generation
> residential router, but I suspect will have utility. Comments to the
> list, please.

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.

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

---

From: Fred Baker <[email-masked]>
Date: Mon, 31 Jan 2011 07:18:04 +0000

> 802.15.4 to ethernet so if you want ot interconnect them you;r egoing to

Pretty much. And there are some interesting issues even in that; an 802.15.4 device can (due to radio behavior) change from one router to another and not realize it, or so I'm told. "802" doesn't mean "Ethernet". It is just the IEEE's way of saying "Local Area Communication Networks".

---

From: Jack Bates <[email-masked]>
Date: Mon, 31 Jan 2011 09:07:56 -0600

> draft-wbeebee-v6ops-ipv6-cpe-router-bis?
5.4 TBD? Does this apply to the draft itself or that another draft will 
have to determine the details of multi-router prefix delegation and 
routing behavior?

I ask, as it's the primary reason I joined v6ops, and there is serious 
concerns dealing with methodology. For example, determining when it's 
appropriate to run DHCPv6 server or DHCPv6 relay agent (or the worst 
yet, proxy-ND through multiple routers). An ISP not issuing IA_PD 
requires multiple proxy-ND. An ISP issuing /60-64 might require DHCPv6 
relay agent to feed a new assignment to each router (with /64, each 
router may need to make multiple requests). An ISP issuing /56 or /48 
probably does not want to issue such a large block to multiple routers 
at the same location, requiring DHCPv6 server to pass them on. Finally, 
a reasonable mechanism for dividing up a /56 or /48 to get proper width 
and depth in a network through automated delegation should be 
documented. I'm personally for an extension in DHCPv6 to support size 
requests, allowing for DHCPv6 relay if the request is met precisely (or 
when multiple requests are necessary due to it being answered with a 
longer length than requested) and DHCPv6 server for when the request is 
answered with a shorter length.

Sorry for being IETF clueless and continuing my bad habit of rambling.

Jack

---

From: Fred Baker <[email-masked]>
Date: Mon, 31 Jan 2011 15:59:13 +0000

On Jan 31, 2011, at 3:07 PM, Jack Bates wrote:

> 5.4 TBD? Does this apply to the draft itself or that another draft will have to determine the details of multi-router prefix delegation and routing behavior?

In my opinion, a requirements document should specify requirements, not solutions. Ideally, they could point to an RFC on the topic; if they want, they could simply say that routers designed for small networks need a solution to the problem.

> I ask, as it's the primary reason I joined v6ops, and there is serious concerns dealing with methodology. For example, determining when it's appropriate to run DHCPv6 server or DHCPv6 relay agent (or the worst yet, proxy-ND through multiple routers). An ISP not issuing IA_PD requires multiple proxy-ND. An ISP issuing /60-64 might require DHCPv6 relay agent to feed a new assignment to each router (with /64, each router may need to make multiple requests). An ISP issuing /56 or /48 probably does not want to issue such a large block to multiple routers at the same location, requiring DHCPv6 server to pass them on. Finally, a reasonable mechanism for dividing up a /56 or /48 to get proper width and depth in a network through automated delegation should be documented. I'm personally for an extension in DHCPv6 to support size requests, allowing for DHCPv6 relay if the request is met precisely (or when multiple requests are necessary due to it being answered with a longer length than requested) and DHCPv6 server for when the request is answered with a shorter length.

Maybe you would like to help specify a solution?

---

From: Jack Bates <[email-masked]>
Date: Mon, 31 Jan 2011 10:04:50 -0600

On 1/31/2011 9:59 AM, Fred Baker wrote:
> In my opinion, a requirements document should specify requirements,
> not solutions. Ideally, they could point to an RFC on the topic; if
> they want, they could simply say that routers designed for small
> networks need a solution to the problem.
>

Okay. This makes sense. We need the solution document to point to with 
the requirements document. It amazes me that one hasn't been designed 
this far into the end game.

> Maybe you would like to help specify a solution?

If someone is interested, I'll be happy to help. Given my lack of 
knowledge on writing drafts, I'd absolutely fail at writing it myself in 
any timely manner.

We have to deal with this problem or everyone is going to be stuck with 
single CPE setups.

Jack

---

From: Fred Baker <[email-masked]>
Date: Mon, 31 Jan 2011 16:56:13 +0000

On Jan 31, 2011, at 4:04 PM, Jack Bates wrote:

> Okay. This makes sense. We need the solution document to point to with the requirements document. It amazes me that one hasn't been designed this far into the end game.

There have been a couple of proposals:

(1) http://tools.ietf.org/html/draft-baker-ipv6-prefix-subdelegation

This is targeted at residential/SOHO networks, and has drawbacks pointed out in the draft if I recall correctly.

(2)
http://tools.ietf.org/html/draft-sarikaya-netext-prefix-delegation
http://tools.ietf.org/html/draft-sarikaya-int-area-prefix-delegation
http://tools.ietf.org/html/draft-sarikaya-intarea-prefix-delegation
http://tools.ietf.org/html/draft-sarikaya-v6ops-prefix-delegation

This is targeted at mobile networks. We have discussed it as recently as IETF-79. In the SurveyMonkey survey we ran at that meeting, 26.7% of respondents said that the draft was unsalvageable or uninteresting and should be abandoned, 53.3% said it should be adopted as a working group draft. and the remainder said it was in the wrong working group or should be an individual effort. That's an interesting range of opinion. I think Mr Sarikaya would be interested to discuss it if you think it is valuable.

(3)
I'm not finding it, but IIRC Ralph Droms and others put in a document saying in essence that the ISP should delegate a prefix to its customer's CPE router, and other routers in the domain should use RFC 3633 to get a /64 delegated to their various interfaces from the CPE. The drawback here is that it is a manual process - the CPE must somehow know what to tell the various routers that enquire of it, and no procedure is defined for identifying what routers share a LAN in the home unless that LAN is directly attached to the CPE.

From my perspective, (3) makes the most sense for residential/SOHO routers, but it needs a disambiguation procedure. If you have a home/residential network that is structured other than as a tree, what routers share links in a manner that is invisible to the CPE? You could solve that with an Alternate Tuesday rule, for example. 

Imagine:
                        |                 |
                        |  +-----------+  | prefix:1::/64
                        +--+ His Office+--+
                        |  +-----------+  |
                        |                 |
             +-------+  |                 |
 ISP --------+  CPE  +--+  +-----------+  | prefix:2::/64
             | Router|  +--+ Her Office+--+
             +-------+  |  +-----------+  |
                        |                 |
                    prefix:0::/64
                        |  +-----------+  |
                        +--+ A/V Router+--+
                        |  +-----------+  | prefix:4::/64
                        |                 |

So the ISP gives the CPE a /60 (say), and the CPE allocates a /64 to each distinct LAN attached to it (perhaps a wired and a wireless LAN). The other routers each observe that they have another interface and don't know what to assign to it, ask the CPE router (the one advertising an RA to them), and it gives them each another prefix, in the above tagged as prefix:1::, prefix:2::, prefix:3::, and prefix:4::. Note that the two offices share connectivity that doesn't go throughout the home, but we now have two prefixes on it. From one perspective, that's not really a problem, as IPv6 allows multiple prefixes on a LAN. On the other hand, it's a bit wasteful, and one could probably find ways to make things really messy. It would be nice if one of the two gave way to the other in some predictable way and was returned to the CPE or re-delegation to some other router should the need arise.

---

From: Jack Bates <[email-masked]>
Date: Mon, 31 Jan 2011 11:47:41 -0600

> There have been a couple of proposals:

I'll read through them. However, I think we could accomplish most of it 
(except for the actual algorithm for finding necessary space in a 
delegation).

draft-ietf-v6ops-ipv6-cpe-router-07

   WPD-2:  The IPv6 CE router MAY indicate as a hint to the delegating
            router the size of the prefix it requires.  If so, it MUST
            ask for a prefix large enough to assign one /64 for each of
            its interfaces rounded up to the nearest nibble and MUST be
            configurable to ask for more.

Really needs to be SHOULD, to support proper support and 
interoperability in a chained environment. It is likely that most 
providers (though not always) will provide a hard set prefix, while it 
is better for chained CPE's to support prefix hinting. If a CPE is to be 
fully interoperable with chaining, this actually would need to be MUST.

WPD-3:  The IPv6 CE router MUST be prepared to accept a delegated
            prefix size different from what is given in the hint.  If the
            delegated prefix is too small to address all of its
            interfaces, the IPv6 CE router SHOULD log a system management
            error.

It should also attempt to do multiple delegation requests to support 
providers that will happily hand out multiple /64 networks, one per 
request. Proper methodology would be to use additional IAIDs.

Per RFC3633 Section 6, Identity Association for Prefix Delegation

"  The IAID uniquely identifies the IA_PD and must be chosen to be
    unique among the IA_PD IAIDs on the requesting router.  The IAID is
    chosen by the requesting router.  For any given use of an IA_PD by
    the requesting router, the IAID for that IA_PD MUST be consistent
    across restarts of the requesting router.  The requesting router may

    maintain consistency either by storing the IAID in non-volatile
    storage or by using an algorithm that will consistently produce the
    same IAID as long as the configuration of the requesting router has
    not changed.  If the requesting router uses only one IAID, it can use
    a well-known value, e.g., zero.
"

Items which are missing are the methodology for staging from one 
topology type to another. Some of this is covered under 
ipv6-cpe-router-bis, in the form of proxy-ND support. It is my belief 
that we could expand upon that with existing RFC's, especially with the 
minor changes to draft-ietf-v6ops-ipv6-cpe-router-07.

A likely sequence of determining the appropriate model is,

1) If we receive larger than our HINT, we support subdelegation of what 
we've received to downstream IA_PD requestors.

2) If we receive exactly the size of our HINT, we perform DHCPv6 Relay 
for our downstream requestors

3) If we receive smaller than our HINT, we should make additional 
requests using additonal IAIDs based on the prefix size we did receive 
(this is for completeness, as it should be in cpe-router).

4) If we do not receive an IA_PD, we perform proxy-ND (which should be 
able to be infinitely chained, even if extremely ugly)

If we are performing subdelegation, we will need to keep certain things 
in mind:

1) We should limit the size requested downstream (we're a cpe router, so 
getting a /48 request would be excessive)

2) If a request exceeds what we have available, we need to request with 
another IAID from upstream for another block (we received a /60, between 
our assignments and downstream assignments, we can no longer answer a 
/63 request, so we must ask upstream for another /60).

The above creates a model that supports:

proxy-nd if the ISP or upstream CPE refuses to do DHCPv6-PD.

multiple exact match prefixes for local use and downstream use if ISP 
supports very small prefixes (at the cost that the ISP will have to 
support additional routes to the max they will allow the customer 
network to have).

Large delegation from ISP, with all internal network CPEs doing DHCPv6 
relay for exact match prefixes. This increases the customer's internal 
routing table (unless over time CPE's recognize subdelegations and 
increase their hint?), but allows for extremely efficient use of the 
space delegated.

Thoughts? Opinions? Am I wrong to think that as a whole this could be 
covered with minor changes to ipv6-cpe-router and ipv6-cpe-router-bis?

Jack

---

From: Ole Troan <[email-masked]>
Date: Mon, 31 Jan 2011 21:03:13 +0100

lots of (old) proposals in this space:

      http://tools.ietf.org/html/draft-noisette-zerouter-frmwk-00
      http://tools.ietf.org/html/draft-marce-zerouter-archi-00
      http://tools.ietf.org/html/draft-linton-zerouter-requirements-00
      http://tools.ietf.org/html/draft-dimitri-zospf-00
      http://tools.ietf.org/html/draft-chelius-router-autoconf-00
      http://tools.ietf.org/html/draft-linton-arcp-00
      RFC4903 - Multi-link subnet issues
      http://tools.ietf.org/html/draft-linton-arcp-00
      RFC4389 - ND Proxy
      http://tools.ietf.org/html/draft-baker-ipv6-prefix-subdelegation-00
      http://conferences.sigcomm.org/sigcomm/2007/ipv6/1569041157.pdf

suggested requirements:
 1) work in an arbitrary topology (including loops)
 2) be zero-configuration
 3) support both unicast and multicast routing
 4) create correct ULA/multicast and "administrative" boundaries
 5) support a network with multiple IPv6 CE router (multi-homed)
 6) support distribution of other configuration information	

any other requirements, that we can use to compare proposed solutions to?

cheers,
Ole

---

From: Jack Bates <[email-masked]>
Date: Mon, 31 Jan 2011 15:04:53 -0600

>        http://conferences.sigcomm.org/sigcomm/2007/ipv6/1569041157.pdf

Is there an existing proposal for provider side? I ask, as the two sorta 
go hand in hand. As part of my process of determining the most efficient 
overall scheme, I've written up some starting logic for the DHCPv6 
server to adapt to more efficient CPE/ISP/routing abilities. It's VERY 
rough.

http://geekmerc.livejournal.com/1846.html

---

From: Mark Smith <[email-masked]>
Date: Tue, 1 Feb 2011 07:36:23 +1030

On Mon, 31 Jan 2011 11:47:41 -0600

> fully interoperable with chaining, this actually would need to be MUST.

I disagree (as I have before). The link between the customer and the
ISP should be a routing aggregation boundary, so that the customer's
topology and topology changes are hidden from the ISP. Allocate a /56
or /48 to the customer (or what ever size the ISP is operationally
comfortable with), and then leave it up to them what they do with it.

Consider the operational consequences of allowing customers to make
dynamic subnet requests -

- your customer aggregation routers will now have additional control
  plane load of processing those requests. This may also create involve
  additional load on backend authentication servers. Some malicious
  customers (let's call then "kids") might use this as a DoS vector,
  for Saturday afternoon entertainment.

- you can't as easily predict your customer address space usage, as it
  is potentially constantly and unpredictably changing over time.

- you're going to have to record each and every request and release
  of /64s, so that you can determine which customer who was using a
  particular /64 at a particular time in the past, for troubleshooting
  or law enforcement purposes.

Some people may be tempted to mitigate some of the above by reserving
a maximum assignment per customer e.g. a /48 per customer and then only
facilitating the dynamic /64 requests from within that /48. That
mitigates two out of the three above, leaving just the processing of
these requests. What value does that processing now add? Why bother?
Simplify everything by just giving everybody a /48 (or /56 etc.) and be
done with it.

---

From: Mark Smith <[email-masked]>
Date: Tue, 1 Feb 2011 07:47:22 +1030

On Mon, 31 Jan 2011 21:03:13 +0100

>  6) support distribution of other configuration information

I'd be curious as to what sort of other configuration information is to
be distributed. If it is starting to including things like DNS server
addresses etc., the above is starting to sound like requirements for
both automated topology discovery and service discovery. That's not a
bad thing, however it then may be worth reviewing what other previous
examples have been capable of distributing to help with
defining requirements e.g. Novell's NDS and NLSP, and Apple's NBP and
similar.

---

From: Jack Bates <[email-masked]>
Date: Mon, 31 Jan 2011 15:18:42 -0600

>    for Saturday afternoon entertainment.

The same can be done with a single device making repetitive requests. 
Control knobs are necessary to protect the ISP in either case. In this 
case, the CPE itself can self rate-control such requests.

>    is potentially constantly and unpredictably changing over time.

This is true, though depending on what they are requesting, sparse 
allocation can resolve this easily enough.

>    or law enforcement purposes.

This you do not have to do. You have the DHCPv6 server record the 
allocation, not the delegation (we reserve a /48, for example, but give 
out networks within that to the same customer).

> Simplify everything by just giving everybody a /48 (or /56 etc.) and be

Customer is connected to the ISP with bridged DSL modem. Customer 
connects a switch to the modem and then connects 2 Linksys to the 
switch. ISP isn't going to handle the customer 2x /48 networks.

Granted, ISP could restrict it and say "Only 1 routed device per 
connection, period!" However, I see no problem with making it more 
expansive and not forcing this limitation on an ISP.

Requests from CPE doing DHCPv6 relay will not be excessively more than a 
single CPE being plugged and unplugged (or the connection to it 
flapping). Rate limits should be applied to protect routers, servers, 
and authentication systems anyways.

Jack

---

From: Ole Troan <[email-masked]>
Date: Mon, 31 Jan 2011 22:27:57 +0100

Mark,

> defining requirements e.g. Novell's NDS and NLSP, and Apple's NBP and

e.g. DNS servers.
would there be any point to be able to do automatic prefix assignment within a network, but not be able to distribute something as vital as DNS server information? wouldn't that leave you with a network you'd have to manually configure anyway...

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Mon, 31 Jan 2011 22:29:13 +0100

Jack,

> Is there an existing proposal for provider side? I ask, as the two sorta go hand in hand. As part of my process of determining the most efficient overall scheme, I've written up some starting logic for the DHCPv6 server to adapt to more efficient CPE/ISP/routing abilities. It's VERY rough.

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.

cheers,
Ole

---

From: Jack Bates <[email-masked]>
Date: Mon, 31 Jan 2011 15:36:19 -0600

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.

Jack

---

From: Jack Bates <[email-masked]>
Date: Mon, 31 Jan 2011 15:39:18 -0600

On 1/31/2011 3:27 PM, Ole Troan wrote:
> would there be any point to be able to do automatic prefix assignment
> within a network, but not be able to distribute something as vital as
> DNS server information? wouldn't that leave you with a network you'd
> have to manually configure anyway...

I would think this would still fall into the DHCPv6 family, though. 
There would be concern of each having it's own local DNS registries, but 
we are talking about routers, and I don't necessarily see this as bad 
for zeroconf.

Jack

---

From: Ole Troan <[email-masked]>
Date: Mon, 31 Jan 2011 22:50:05 +0100

Jack,

> To be honest, there is no administrative boundary in zeroconf CPEs today. Boundaries only form when a customer starts to actually manage their CPE.

the basic IPv6 CE router requirements document certainly specifies a boundary.
I would claim that most routed CPEs implement a boundary for IPv4, by the fact that they do NAT.

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

one is what you would get from a Basic IPv6 CPE router requirements compliant CPE.
I don't see the restriction. just hand out another /56 or /48 to the second CPE...

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 01 Feb 2011 10:50:13 +1300

> comfortable with), and then leave it up to them what they do with it.

+1. The customer's subnet structure is nothing to do with the ISP.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Tue, 1 Feb 2011 08:26:13 +1030

On Mon, 31 Jan 2011 15:18:42 -0600
Jack Bates <[email-masked]> wrote:

So, taking a step back, what are you going to gain from all this? How
is this going to save you or make you money as an ISP? Considering that
as an ISP you're going to have a minimum of a /32, or 4.3 billion /64s
(for the princely sum of e.g. $2250 per annum from ARIN), is
the cost of potentially tracking them and assigning them individually
worth the benefit?

> > dynamic subnet requests -
<snip>

---

From: Jack Bates <[email-masked]>
Date: Mon, 31 Jan 2011 16:06:26 -0600

On 1/31/2011 3:50 PM, Ole Troan wrote:
> the basic IPv6 CE router requirements document certainly specifies a
> boundary. I would claim that most routed CPEs implement a boundary
> for IPv4, by the fact that they do NAT.
>

True, and these boundaries exist in CPE stacked environments that aren't 
reconfigured (when they actually work by default). I'd expect similar 
out of IPv6 CPEs.

Though I think the biggest thing to view in a zeroconf CPE is the 
ability to tell when it is behind another CPE versus connected to a 
provider (so it can change it's behavior automatically).

Even with this capability, it should be up to the provider to decide how 
they deploy prefix deployment in an automated fashion. No provider will 
accept sending a /48 to each CPE connected direct to it. A /48 per site 
is fine, but do we really want to limit how the customer connects? This 
should be site policy, not specification policy.

> one is what you would get from a Basic IPv6 CPE router requirements
> compliant CPE. I don't see the restriction. just hand out another /56
> or /48 to the second CPE...

The argument is that most providers (me included) consider it obscene to 
issue 2+ /48's to a single customer site because of how they decided to 
connect the CPE. Yet restricting it to a single /48 per customer 
interface creates it's own limitations on the customer. I'm much more 
tolerable of issuing multiple /56 networks, but then we've just promoted 
issuing smaller networks to customers just in case they plug stuff in a 
certain way.

The workaround is to allow for implementations which can support a more 
versatile numbering scheme from the ISP itself.

 From a CPE perspective, it won't matter. If the CPE requests a /63 to 
number it's 2 LAN interfaces, the ISP can either give it

nothing - we'll have to do proxy-nd to the wan
/64 - we'll have to issue another request with a different IAID
/63 - we're good locally, we can request more if we get a PD request 
(preferable, and allows for a prefix change request if ISP supports it) 
or we can do relay if necessary)

the ISP hands out a larger (technically shorter) prefix which tells us 
we're currently good for subdelegations. Even if the prefix runs out, we 
can request another with a different IAID (if the ISP will permit 
another, but good for ISPs that did decide to just issue multiple /60 
networks).

Jack

---

From: Jack Bates <[email-masked]>
Date: Mon, 31 Jan 2011 16:14:17 -0600

> the cost of potentially tracking them and assigning them individually

Promotion of versatility in the specifications.

An ISP MAY choose to issue only 1 /48 per customer circuit, forcing them 
to only 1 routed CPE interfaced with the ISP

An ISP MAY choose to issue multiple /64, /60, /56, /48 to a customer 
circuit, allowing multiple routed CPEs interfaced with the ISP at the 
cost of either wasted space or shortening the customer space, possibly 
causing multiple requests from a single routed CPE which increases the 
routing table.

An ISP currently CANNOT choose to reserve a /48 for a customer interface 
and delegate addresses from it to any number of routed CPE devices, with 
sparse allocation techniques between directly adjacent CPEs to assist 
routing ISP routing and delegation aggregation, CPE aggregation 
techniques to increase the size of the networks but reduce their number 
over time, etc.

Jack

---

From: Michael Newbery <[email-masked]>
Date: Tue, 1 Feb 2011 11:14:50 +1300

> On 2011-02-01 10:06, Mark Smith wrote:
[snip]
> +1. The customer's subnet structure is nothing to do with the ISP.

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

---

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

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.

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

---

From: Ole Troan <[email-masked]>
Date: Mon, 31 Jan 2011 23:46:19 +0100

Jack,

> True, and these boundaries exist in CPE stacked environments that aren't reconfigured (when they actually work by default). I'd expect similar out of IPv6 CPEs.
> 
> Though I think the biggest thing to view in a zeroconf CPE is the ability to tell when it is behind another CPE versus connected to a provider (so it can change it's behavior automatically).

yep, proposals for how this could be done would be appreciated.

> Even with this capability, it should be up to the provider to decide how they deploy prefix deployment in an automated fashion. No provider will accept sending a /48 to each CPE connected direct to it. A /48 per site is fine, but do we really want to limit how the customer connects? This should be site policy, not specification policy.

I don't see the limitation you are talking about...

> The argument is that most providers (me included) consider it obscene to issue 2+ /48's to a single customer site because of how they decided to connect the CPE. Yet restricting it to a single /48 per customer interface creates it's own limitations on the customer. I'm much more tolerable of issuing multiple /56 networks, but then we've just promoted issuing smaller networks to customers just in case they plug stuff in a certain way.
> 
> The workaround is to allow for implementations which can support a more versatile numbering scheme from the ISP itself.
> 
> From a CPE perspective, it won't matter. If the CPE requests a /63 to number it's 2 LAN interfaces, the ISP can either give it

please see the discussion a month or two ago. the CPE has not information available to request a certain prefix size.

> /63 - we're good locally, we can request more if we get a PD request (preferable, and allows for a prefix change request if ISP supports it) or we can do relay if necessary)
> 
> the ISP hands out a larger (technically shorter) prefix which tells us we're currently good for subdelegations. Even if the prefix runs out, we can request another with a different IAID (if the ISP will permit another, but good for ISPs that did decide to just issue multiple /60 networks).

how the provider deals with delegating prefixes and the size of the prefix is up to provider policy.
there is nothing stopping a provider from assigning whatever sized prefix to whatever number of connected CPEs in a single site.

you cannot expect to rely on a hint in the PD message to determine the size to delegate, nor can the provider depend on multiple IAIDs in the request.

cheers,
Ole

---

From: Jack Bates <[email-masked]>
Date: Mon, 31 Jan 2011 16:59:05 -0600

On 1/31/2011 4:46 PM, Ole Troan wrote:
>
> please see the discussion a month or two ago. the CPE has not
> information available to request a certain prefix size.
>

CPE has the information available to

1) request it's immediate needs if it's virgin

2) request an aggregate of it's needs and all subtending needs if it has 
active prefix information.

As I have mentioned, the ability for a CPE to expand it's prefix with 
the ISP is also of great benefit in this case.

>
> how the provider deals with delegating prefixes and the size of the
> prefix is up to provider policy. there is nothing stopping a provider
> from assigning whatever sized prefix to whatever number of connected
> CPEs in a single site.
>

A mechanism isn't documented for a variable prefix layout. As you said, 
the CPE (especially virgin) has no idea what it's future needs might be. 
If the ISP hands it a large prefix, it has what it has to work with. 
However, an ISP should be able to support more, handing out portions of 
a /48 to a customer site regardless of how they connect routers to the ISP.

> you cannot expect to rely on a hint in the PD message to determine
> the size to delegate, nor can the provider depend on multiple IAIDs
> in the request.

Depend, no. Which is why I wrote up a rough idea of ISP logic which 
could compensate for a variety of dumb and smart CPEs. The HINT is 
useful in making determinations. Lack of a HINT can be answered in a 
number of ways. As for multiple IAIDs, if CPEs aren't FORCED to support 
this, we will have problems when delegations are too small for what is 
required (unless we just want to sit back and proxy-nd everything when 
we are out of prefix space).

Jack

---

From: Ole Troan <[email-masked]>
Date: Tue, 1 Feb 2011 00:35:33 +0100

Jack,

> 1) request it's immediate needs if it's virgin

unless the CPE is configured with this information it has no available information to know the size required to number the site behind it.

> 2) request an aggregate of it's needs and all subtending needs if it has active prefix information.
> 
> As I have mentioned, the ability for a CPE to expand it's prefix with the ISP is also of great benefit in this case.

"expanding" the site can only be done either by renumbering or doing flat as in /64s prefix delegation.

> A mechanism isn't documented for a variable prefix layout. As you said, the CPE (especially virgin) has no idea what it's future needs might be. If the ISP hands it a large prefix, it has what it has to work with. However, an ISP should be able to support more, handing out portions of a /48 to a customer site regardless of how they connect routers to the ISP.

then hand out /56s to up to 256 CPEs.

> Depend, no. Which is why I wrote up a rough idea of ISP logic which could compensate for a variety of dumb and smart CPEs. The HINT is useful in making determinations. Lack of a HINT can be answered in a number of ways. As for multiple IAIDs, if CPEs aren't FORCED to support this, we will have problems when delegations are too small for what is required (unless we just want to sit back and proxy-nd everything when we are out of prefix space).

with a /56 a end user site has 2^8 number of prefixes, do we think that will ever run out? if so, he can justify a request for whatever he needs.

you can either do flat delegation and expose the internal topology of the end user site to the SP or you can do aggregated delegation.  you _could_ imagine a CE using multiple IAIDs to request additional bits of address space. but that would complicate sub-delegation a lot. all the proposals I'm aware of are based on a single site prefix being subdelegated...

in any case I don't think there is anything for the Basic IPv6 CE document here. but lots of opportunities for a home networking architecture one, so I look forward to drafts! ;-)

cheers,
Ole

---

From: Jack Bates <[email-masked]>
Date: Mon, 31 Jan 2011 17:58:16 -0600

> unless the CPE is configured with this information it has no available information to know the size required to number the site behind it.
It's immediate needs are it's routed interfaces - wan worth of /64. 
That's easy to know and request. It can even set by the manufacturer 
going out the door if they don't want the software to count.

> "expanding" the site can only be done either by renumbering or doing flat as in /64s prefix delegation.
Yes, renumbering is one option. Supporting a HINT with prefix + length 
covering only a duid's range and falling within the network reserved for 
the customer would also be a nice way to handle it. Then the addressing 
doesn't have to change behind the first CPE, and it's just the database 
in the ISP server and the CPE which are correcting themselves.

A router should automatically be able to recognize contiguous 
assignments to a single next-hop and aggregate the route.

> then hand out /56s to up to 256 CPEs.
That is an option; just not a scalable one.

> with a /56 a end user site has 2^8 number of prefixes, do we think 
> that will ever run out? if so, he can justify a request for whatever 
> he needs.
The same thing I'm discussing for the ISP works within a CPE network for 
zeroconf. Among other things it would better utilize a /56, however, if 
using sparse delegation model in combination of upgrading requested 
prefixes when you are handing more out downstream, and keeping routing 
tables small in the process, a /48 would be better.

> in any case I don't think there is anything for the Basic IPv6 CE document here. but lots of opportunities for a home networking architecture one, so I look forward to drafts! ;-)

With all the things a basic CPE does these days, why not? I thought the 
point of a basic CPE was to handle zeroconf. Less exposure to the SP is 
required if you can relabel your prefix length (oops, another subtending 
router, bump my /63 request to a /60 as he's asking for a /61). This 
theoretically would be accomplished with a renewal request which just 
asked the SP for a larger prefix, which the SP could verify didn't 
conflict with anything else it delegated to the customer.

It's not much different than a customer's site asking for multiple IPv4 
addresses as they plug in additional CPEs direct to the SP. The main 
difference comes in the prefix delegation for each of those CPEs and how 
to best handle that in an automated way which allows providers to set 
their policies but still allows for plug and play.

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

Jack

---

From: Sam Silvester <[email-masked]>
Date: Tue, 1 Feb 2011 13:37:15 +1030

On Tue, Feb 1, 2011 at 7:48 AM, Jack Bates <[email-masked]> wrote:
> Control knobs are necessary to protect the ISP in either case. In this case,
> the CPE itself can self rate-control such requests.

I don't know that I'd be comfortable trusting the CPE with this
responsibility unless I as the service provider managed it; in fact,
in many cases for residential ISPs, the customer owns / manages their
own CPE (and are even welcome to bring their own as opposed to buying
the one their ISP provides).

Sam

---

From: Jack Bates <[email-masked]>
Date: Mon, 31 Jan 2011 21:45:35 -0600

> the one their ISP provides).

Oh, I agree. I meant that as "in addition to" the ISP controls. There's 
no reason every step of the process couldn't have DHCPv6 controls to 
limit excessive requests, especially for DHCPv6-PD. It's precisely the 
"customer buys own CPE" that raises my issues with the lack of a good 
diverse model, both for the ISP as well as support in the CPE market.

Jack