headers
Sam Silvester | 1 Feb 2011 04:07
Picon

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

On Tue, Feb 1, 2011 at 7:48 AM, Jack Bates <jbates@...> wrote:
> On 1/31/2011 3:06 PM, Mark Smith wrote:
>>
>> 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.
>
> 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.

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
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Permalink | Reply | 1 comment |
headers
Jack Bates | 1 Feb 2011 04:45

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

On 1/31/2011 9:07 PM, Sam Silvester wrote:
> 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).

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
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Permalink | Reply | 0 comments |
headers
Ole Troan | 1 Feb 2011 13:21
Favicon

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

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

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Permalink | Reply | 0 comments |
headers
Fred Baker | 1 Feb 2011 16:03
Picon
Favicon

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


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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jack Bates | 1 Feb 2011 16:38

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


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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Smith | 1 Feb 2011 21:16

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

On Mon, 31 Jan 2011 16:30:16 -0600
Jack Bates <jbates@...> 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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lee Howard | 2 Feb 2011 01:27

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


> -----Original Message-----
> From: v6ops-bounces@...
[mailto:v6ops-bounces@...] On Behalf Of
Jack Bates
>
> 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)

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

_______________________________________________
v6ops mailing list
v6ops@...
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jack Bates | 2 Feb 2011 02:12

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

On 2/1/2011 6:27 PM, Lee Howard wrote:
> 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.
>
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.

> Issue multiple prefixes per customer, if you support multiple routers.  If
> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian E Carpenter | 2 Feb 2011 03:02
Picon

[Fwd: I-D Action:draft-ietf-v6ops-v4v6tran-framework-01.txt]

This is a very small update as promised in the WGLC message.

-------- Original Message --------
Subject: I-D Action:draft-ietf-v6ops-v4v6tran-framework-01.txt
Date: Tue, 01 Feb 2011 17:45:03 -0800
From: Internet-Drafts@...
Reply-To: internet-drafts@...
To: i-d-announce@...
CC: v6ops@...

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title           : Framework for IP Version Transition Scenarios
	Author(s)       : B. Carpenter, et al.
	Filename        : draft-ietf-v6ops-v4v6tran-framework-01.txt
	Pages           : 7
	Date            : 2011-02-01

This document sets out a framework for the presentation of scenarios
and recommendations for a variety of approaches to the transition
from IPv4 to IPv6, given the necessity for a long period of co-
existence of the two protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v4v6tran-framework-01.txt

_______________________________________________
v6ops mailing list
v6ops@...
(Continue reading)

Permalink | Reply | 1 comment |
headers
Martin Millnert | 2 Feb 2011 04:01
Picon

Re: v6-aaaa-whitelisting-implications -- Recommended Practice?

Jason,

On Mon, 2011-01-31 at 19:13 +0000, Livingood, Jason wrote:
> Thanks for the feedback, and for the reference suggested at the end. I'll
> add that to the -02 update, as well ensure that any speculation is
> explicitly described as such.
> 
> BTW, based on your email, sounds like good input for an "Objectives for
> World IPv6 Day" document!

A friend pointed out to me recently the logical fallacy in what I was
suggesting the other day:  It is impossible to measure how many Internet
hosts  can/can't reach you because you have a AAAA on, ... when you have
a AAAA on.

Oops. 

I guess we will have to make do with some keeping our ears out for
unusual problems reported to ISPs support desks and similar
L8-expressions of brokenness.

Cheers,
Martin

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
(Continue reading)

Permalink | Reply | 0 comments |

Gmane