RE: [dhcwg] Unnecessary restriction in DHCP-PD?

["Stark, Barbara" <bs7652@att.com>]

The unnumbered model provides considerable scalability advantages in the
access network of some service providers. I suspect that whether or not
you choose to include it in the CPE router draft, the functionality to
support this will be required and present in routers supplied by such
service providers. Retail routers vendors will choose whether they want
to provide routers that also have this function.

As demonstrated by PPPoE (which is an informational RFC, and not a
standard), service providers have no problem using solutions that make
sense, whether or not the IETF blesses them as standards. And CPE
vendors have no problem implementing these solutions, if it makes
business sense.

We also have a very strict requirement that routers not do router
advertisement to the WAN. I continue not to see a problem with the
unnumbered model.
Barbara

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
Behalf Of Hemant Singh (shemant)
Sent: Thursday, October 30, 2008 11:31 AM
To: Suresh Krishnan; IPv6 Operations
Subject: RE: [dhcwg] Unnecessary restriction in DHCP-PD?

Folks,

We never liked the Unnumbered model that was asked to be put in our CPE
Rtr draft.  Well, after this discussion a nail in the coffin for the
Unnumbered model has been found.  Due to this totally valid restriction
in the DHCP-PD RFC3633, we need to remove the Unnumbered model from the
CPE rtr draft.  The reason is because in the Unnumbered model, an IPv6
address from the IA-PD was used for the source of upstream traffic to
the Service Provider.   Any comments?

Thanks.

Hemant & Wes

-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf
Of Suresh Krishnan
Sent: Wednesday, October 22, 2008 11:42 AM
To: David W. Hankins
Cc: DHC WG
Subject: Re: [dhcwg] Unnecessary restriction in DHCP-PD?

Hi David,
   Thanks for your comments. Please find responses inline.

David W. Hankins wrote:
> On Fri, Oct 17, 2008 at 06:36:12PM -0400, Suresh Krishnan wrote:
>>   I read Ole's mail on v6ops as well, but I still do not see the 
>> technical problem. I am running this setup currently and I am not
seeing any issues.
>> To narrow down my question, "what exactly breaks when we do this?"
> 
> It is an administrative question, not so much a technical one.

Ack. I think this might be a good explanation for this restriction.

> 
> The PD client is a client, not representing the network administrator,

> on the upstream-facing interface.  It is inappropriate to make changes

> to the network's management.  If the network wished to give the client

> additional addresses on that segment, the RA PIOs and/or IA_NA would 
> already reflect that.
> 
> Having a delegated prefix does not grant the right to manage the 
> upstream's network.
> 
> 
> Note however that if the PD client was operating as a DHCPv6 server on

> its upstream facing interface as well as advertising the delegated 
> prefixes there, a recursion error would be present; a client on the 
> upstream side may acheive a prefix delegation from a PD client on the 
> same link, which in turn is a client of the upstream network, and so 
> on.

This was not my intent (to re-advertize the prefix upstream) but to just
use a configured address. I realize now that pursuing this might be more
trouble than it is worth. I am probably better off getting a DHCPv6
address or a SLAAC configured address on the upstream interface.

Thanks
Suresh
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg