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

Jack Bates <jbates@brightok.net> Mon, 31 January 2011 23:55 UTC

Return-Path: <jbates@brightok.net>
X-Original-To: v6ops@core3.amsl.com
Delivered-To: v6ops@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F03233A6C8E for <v6ops@core3.amsl.com>; Mon, 31 Jan 2011 15:55:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.091
X-Spam-Level:
X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27ubTWR4czeC for <v6ops@core3.amsl.com>; Mon, 31 Jan 2011 15:55:15 -0800 (PST)
Received: from phobos.brightok.net (mail1.brightok.net [69.8.2.26]) by core3.amsl.com (Postfix) with ESMTP id E61193A68B1 for <v6ops@ietf.org>; Mon, 31 Jan 2011 15:55:14 -0800 (PST)
Received: from [192.168.1.122] ([69.8.25.3]) by phobos.brightok.net (8.13.6/8.13.6) with ESMTP id p0VNwTRa020523; Mon, 31 Jan 2011 17:58:29 -0600 (CST)
Message-ID: <4D474C98.6000704@brightok.net>
Date: Mon, 31 Jan 2011 17:58:16 -0600
From: Jack Bates <jbates@brightok.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Ole Troan <otroan@employees.org>
References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <B711D39C-5888-4619-B8BF-29A317145E51@cisco.com> <28C56464-559F-431C-8F68-4F0F633992EE@employees.org> <4D4723F5.9000201@brightok.net> <A296A17E-36CC-4E4A-B611-7990FBBD4044@employees.org> <4D472B53.7080400@brightok.net> <86B22269-D7B6-4B1E-978F-51D719B2FB47@employees.org> <4D473262.8060109@brightok.net> <E6019F66-7DC4-4F93-8F8A-19F086B37E02@employees.org> <4D473EB9.6010802@brightok.net> <3F0BB162-030F-45EC-B430-9BA9C53A7439@employees.org>
In-Reply-To: <3F0BB162-030F-45EC-B430-9BA9C53A7439@employees.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Jan 2011 23:55:16 -0000

On 1/31/2011 5:35 PM, Ole Troan wrote:
>
> 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.

> 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! ;-)

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