Re: [v6ops] DHCPv6 vs ND strikes again (was: New version available)

["Brzozowski, John" <[e-mail]>]

To be specific, the IGD could know what it can support based on its
configuration, etc., however, I do agree it could be difficult if not
impossible for the IGG to predict what will be connect to it in the premise.

John

On 10/22/10 4:35 PM, "Ralph Droms" <[e-mail]> wrote:

> Although RFC 3633 might provide a hinting mechanism, there's no good automated
> way for the IGD to know what information to put into that hint.  So there is
> no way for the IGD to ensure it requests a sufficient prefix.
> 
> - Ralph
> 
> On Oct 22, 2010, at 4:32 PM 10/22/10, Brzozowski, John wrote:
> 
>> To be clear, either approach has scale and/or operational challenges.
>> 
>> So I am back to how does an IGD ensure that what it requests a prefix of
>> sufficient size from the operator?  RFC3633 loosely provides a mechanism,
>> why not use it?
>> 
>> 
>> On 10/22/10 4:28 PM, "Ralph Droms" <[e-mail]> wrote:
>> 
>>> Doesn't seem like that will scale very well if there are more than a couple
>>> of
>>> routers in the home network.
>>> 
>>> But what do I know?  I'm not an SP network operator.
>>> 
>>> - Ralph
>>> 
>>> 
>>> On Oct 22, 2010, at 4:26 PM 10/22/10, Brzozowski, John wrote:
>>> 
>>>> Provisioning large blocks across the board may not reliably work either.
>>>> 
>>>> Perhaps the IGD should simply relay downstream IA_PD requests from within
>>>> the premise and let the other RRs negotiate their own prefix requests with
>>>> the operator DHCPv6 servers?
>>>> 
>>>> John
>>>> 
>>>> On 10/22/10 4:20 PM, "Ralph Droms" <[e-mail]> wrote:
>>>> 
>>>>> Just because the IGD has the capability to do hierarchical PD doesn't mean
>>>>> it
>>>>> knows how many prefixes to ask for.
>>>>> 
>>>>> - Ralph
>>>>> 
>>>>> On Oct 22, 2010, at 4:18 PM 10/22/10, Brzozowski, John wrote:
>>>>> 
>>>>>> The IGD has to some degree of awareness to ensure it gets provisioned
>>>>>> appropriately and can in turn support whatever is connected to it within
>>>>>> the
>>>>>> premise.
>>>>>> 
>>>>>> 
>>>>>> On 10/22/10 4:06 PM, "Ralph Droms" <[e-mail]> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> On Oct 22, 2010, at 3:57 PM 10/22/10, Brzozowski, John wrote:
>>>>>>> 
>>>>>>>> Ralph,
>>>>>>>> 
>>>>>>>> The IGD in this would have to know about the sensor network to ensure
>>>>>>>> traffic to it can be routed right?  The IGD at the edge of the customer
>>>>>>>> premise needs to have some awareness some where no?  Even if the IGD
>>>>>>>> was
>>>>>>>> issue a /56, it would still have to support some form of hierarchical
>>>>>>>> PD
>>>>>>>> to
>>>>>>>> provision and enable the sensor network right?
>>>>>>>> 
>>>>>>>> John
>>>>>>> 
>>>>>>> Yes.
>>>>>>> 
>>>>>>> - Ralph
>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 10/22/10 3:49 PM, "Ralph Droms" <[e-mail]> wrote:
>>>>>>>> 
>>>>>>>>> John - regarding the size of the prefix to request, here is a simple
>>>>>>>>> example.
>>>>>>>>> We expect Zigbee IP sensor network to connect through a dual-interface
>>>>>>>>> gateway
>>>>>>>>> to the home network and then to the IGD.  The sensor network needs a
>>>>>>>>> prefix
>>>>>>>>> for the 802.15.4 network, but the IGD only has a single interface.
>>>>>>>>> How
>>>>>>>>> does
>>>>>>>>> the IGD know to ask for a prefix shorter than /64?  In general, how
>>>>>>>>> does
>>>>>>>>> the
>>>>>>>>> IGD know, a priori, the architecture of the residential network so it
>>>>>>>>> can
>>>>>>>>> ask
>>>>>>>>> for an appropriately sized prefix?
>>>>>>>>> 
>>>>>>>>> - Ralph
>>>>>>>>> 
>>>>>>>>> On Oct 22, 2010, at 3:45 PM 10/22/10, Brzozowski, John wrote:
>>>>>>>>> 
>>>>>>>>>> On 10/21/10 5:03 AM, "Ole Trøan" <[e-mail]> wrote:
>>>>>>>>>> 
>>>>>>>>>>> John,
>>>>>>>>>>> 
>>>>>>>>>>> [...]
>>>>>>>>>>> 
>>>>>>>>>>>> as more advanced home networks evolve, it is going to be difficult
>>>>>>>>>>>> for
>>>>>>>>>>>> the
>>>>>>>>>>>> border router to know the number of links that exists or may appear
>>>>>>>>>>>> in
>>>>>>>>>>>> the
>>>>>>>>>>>> future. the intention with PD was always that the prefix size was a
>>>>>>>>>>>> contractual matter, not one which is negotiated 'real time'.
>>>>>>>>>>>> [jjmb] Hmmm...RFC3633 is a contract?
>>>>>>>>>>> 
>>>>>>>>>>> a fax replacement. I'd expect when I buy service from an ISP the
>>>>>>>>>>> contract
>>>>>>>>>>> between me and the ISP also includes the size of the prefix I will
>>>>>>>>>>> be
>>>>>>>>>>> assigned
>>>>>>>>>>> as well as guarantees about its lifetime.
>>>>>>>>>> [jjmb] as stated in other emails we are dealing with protocols not
>>>>>>>>>> contracts.  Brian stated it well, this is between the subscriber and
>>>>>>>>>> operators, not the IETF.
>>>>>>>>>>> 
>>>>>>>>>>> currently the hint in 3633 is just a MAY and even then there is only
>>>>>>>>>>> text
>>>>>>>>>>> suggesting that the requesting router should include a prefix, to
>>>>>>>>>>> hint
>>>>>>>>>>> to
>>>>>>>>>>> the
>>>>>>>>>>> server that it would like to receive the same prefix that was
>>>>>>>>>>> presumably
>>>>>>>>>>> previously delegated. WPD-2 in draft-ietf-v6ops-ipv6-cpe-router-07
>>>>>>>>>>> includes
>>>>>>>>>>> a
>>>>>>>>>>> MAY hint to the delegating router about the size it would require
>>>>>>>>>>> and
>>>>>>>>>>> WPD-3
>>>>>>>>>>> states it MUST accept a different prefix size.
>>>>>>>>>> [jjmb] operators also have there own requirements, which may vary.  I
>>>>>>>>>> for
>>>>>>>>>> one will be requiring the hint.
>>>>>>>>>>> 
>>>>>>>>>>> DHCPv6 PD is a mechanism where the control and policy is at the
>>>>>>>>>>> DHCPv6
>>>>>>>>>>> PD
>>>>>>>>>>> server.
>>>>>>>>>>> 
>>>>>>>>>>> you could write a proposal to strengthen this language, but I would
>>>>>>>>>>> posit
>>>>>>>>>>> that
>>>>>>>>>>> the IPv6 CE is in no position to know a priori what size to ask for.
>>>>>>>>>> [jjmb] really?  An IPv6 CPE has no way to determine how many and what
>>>>>>>>>> sort
>>>>>>>>>> of interfaces it is built to support or configure with?  It is not
>>>>>>>>>> aware
>>>>>>>>>> of
>>>>>>>>>> its configuration which in turn would drive its provisioning request?
>>>>>>>>>> IMO
>>>>>>>>>> this is most certainly something an IGD can and should be
>>>>>>>>>> programmatically
>>>>>>>>>> aware of specifically when initializing.
>>>>>>>>>>> 
>>>>>>>>>>>> mind you, I'm not an operator and I would surely like to understand
>>>>>>>>>>>> the
>>>>>>>>>>>> reasons why doing more negotiation would be useful? of course, one
>>>>>>>>>>>> has
>>>>>>>>>>>> to
>>>>>>>>>>>> expect that every CPE supports a delegation of <=/64. are there
>>>>>>>>>>>> really
>>>>>>>>>>>> implementations which only supports a single /64? if so, I'd claim
>>>>>>>>>>>> that's
>>>>>>>>>>>> a
>>>>>>>>>>>> bug and not in line with 3633 nor the basic ipv6 ce router
>>>>>>>>>>>> requirements
>>>>>>>>>>>> specification.
>>>>>>>>>>>> [jjmb] having flexibility is a must, making substantial fixed
>>>>>>>>>>>> decisions
>>>>>>>>>>>> this
>>>>>>>>>>>> early can result in complications or even limitations.  I
>>>>>>>>>>>> absolutely
>>>>>>>>>>>> agree
>>>>>>>>>>>> with one of your comments above, home networks will evolve.  As
>>>>>>>>>>>> such
>>>>>>>>>>>> we
>>>>>>>>>>>> need
>>>>>>>>>>>> to ensure we have the ability to accommodate the same over time.
>>>>>>>>>>>> An
>>>>>>>>>>>> incremental approach supports this goal.  Yes there are
>>>>>>>>>>>> implementations
>>>>>>>>>>>> that
>>>>>>>>>>>> only support a /64, nothing shorter largely because they physically
>>>>>>>>>>>> do
>>>>>>>>>>>> not
>>>>>>>>>>>> have the need and/or ability to support anything else.  If a device
>>>>>>>>>>>> has
>>>>>>>>>>>> only
>>>>>>>>>>>> one IPv4 LAN and cannot be upgraded to support more (including
>>>>>>>>>>>> hierarchical
>>>>>>>>>>>> PD) why would this be a bug?  I think we will have to agree to
>>>>>>>>>>>> disagree,
>>>>>>>>>>>> I
>>>>>>>>>>>> do not view this as a bug.  I do think this is inline with RFC3633
>>>>>>>>>>>> and
>>>>>>>>>>>> the
>>>>>>>>>>>> IPv6 CPE router requirements.  A lot of work has been done over the
>>>>>>>>>>>> past
>>>>>>>>>>>> couple of years to get some existing routers to be software
>>>>>>>>>>>> upgradable
>>>>>>>>>>>> to
>>>>>>>>>>>> support native IPv6 as such there may be some devices with lesser
>>>>>>>>>>>> capabilities.  Having a minimal level of support for IPv6 is better
>>>>>>>>>>>> than
>>>>>>>>>>>> none, right?  Finally, there may be a wide range of routers built
>>>>>>>>>>>> over
>>>>>>>>>>>> time
>>>>>>>>>>>> that range in caliber and features.
>>>>>>>>>>> 
>>>>>>>>>>> I think we are in agreement. I'm certainly not suggesting that e.g.
>>>>>>>>>>> a
>>>>>>>>>>> /56
>>>>>>>>>>> is
>>>>>>>>>>> the only way it can be done. nor that delegations have to be rigid.
>>>>>>>>>>> every
>>>>>>>>>>> implementation must support any prefix length thrown at it, with the
>>>>>>>>>>> exception
>>>>>>>>>>> of getting a so small address block that it doesn't get a single /64
>>>>>>>>>>> per
>>>>>>>>>>> link.
>>>>>>>>>>> 
>>>>>>>>>>> I'm just saying that the rfc3633 "hint" may not be very useful; and
>>>>>>>>>>> that
>>>>>>>>>>> delegating the absolute minimum address block required may be
>>>>>>>>>>> problematic.
>>>>>>>>>>> for
>>>>>>>>>>> example if the CE after a delegation is done determines that it
>>>>>>>>>>> needs
>>>>>>>>>>> a
>>>>>>>>>>> larger
>>>>>>>>>>> block, the home network may have to be renumbered.
>>>>>>>>>> [jjmb] if a CE can only support the minimum why is it a problem for
>>>>>>>>>> it
>>>>>>>>>> to
>>>>>>>>>> be
>>>>>>>>>> provisioning with the minimum?  If a CE after its initial
>>>>>>>>>> provisioning
>>>>>>>>>> is
>>>>>>>>>> reconfigured to support additional VLANs renumbering will have to
>>>>>>>>>> occur
>>>>>>>>>> anyway no?
>>>>>>>>>>> 
>>>>>>>>>>> thinking of DHCP PD as a fax replacement, lets you not have to think
>>>>>>>>>>> about
>>>>>>>>>>> all
>>>>>>>>>>> the hard corner cases. ;-)
>>>>>>>>>> [jjmb] I still am not clear to the reference to fax replacement,
>>>>>>>>>> sorry.
>>>>>>>>>>> 
>>>>>>>>>>> cheers,
>>>>>>>>>>> Ole
>>>>>>>>>> 
>>>>>>>>>> =========================================
>>>>>>>>>> John Jason Brzozowski
>>>>>>>>>> Comcast Cable
>>>>>>>>>> e) mailto:[e-mail]
>>>>>>>>>> o) 609-377-6594
>>>>>>>>>> m) 484-962-0060
>>>>>>>>>> w) http://www.comcast6.net
>>>>>>>>>> =========================================
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> v6ops mailing list
>>>>>>>>>> [e-mail]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> =========================================
>>>>>>>> John Jason Brzozowski
>>>>>>>> Comcast Cable
>>>>>>>> e) mailto:[e-mail]
>>>>>>>> o) 609-377-6594
>>>>>>>> m) 484-962-0060
>>>>>>>> w) http://www.comcast6.net
>>>>>>>> =========================================
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> =========================================
>>>>>> John Jason Brzozowski
>>>>>> Comcast Cable
>>>>>> e) mailto:[e-mail]
>>>>>> o) 609-377-6594
>>>>>> m) 484-962-0060
>>>>>> w) http://www.comcast6.net
>>>>>> =========================================
>>>>>> 
>>>>> 
>>>> 
>>>> =========================================
>>>> John Jason Brzozowski
>>>> Comcast Cable
>>>> e) mailto:[e-mail]
>>>> o) 609-377-6594
>>>> m) 484-962-0060
>>>> w) http://www.comcast6.net
>>>> =========================================
>>>> 
>>> 
>> 
>> =========================================
>> John Jason Brzozowski
>> Comcast Cable
>> e) mailto:[e-mail]
>> o) 609-377-6594
>> m) 484-962-0060
>> w) http://www.comcast6.net
>> =========================================
>> 
> 

=========================================
John Jason Brzozowski
Comcast Cable
e) mailto:[e-mail]
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=========================================