RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

["Hemant Singh (shemant)" <shemant@cisco.com>]

I think errata for RFC3633 makes sense because there is a means in
stateless DHCPv6 via which the stateless client can ask for IA_PD and no
explicit text in RFC3633 to forbid it. This mailer has a few folks
asking stateless DHCPv6 to obtain IA_PD.  Folks will use any tool
available to them. That is why I say, we should shut the door on this
with an errata.

Thanks.

Hemant

-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Monday, July 21, 2008 7:15 AM
To: Hemant Singh (shemant)
Cc: Ralph Droms (rdroms); Iljitsch van Beijnum; IPv6 Operations
Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

The rapid commit mechanism also uses Solicit and Reply in a two message
Solicit/Reply message exchange that is still requires per- client state
maintenance on the part of the server.  Use of rapid commit for prefix
delegation is unrelated to the use of "stateless"  
DHCPv6 for prefix delegation.

While I agree that there is no explicit exclusion of the use of an IA_PD
in an Information-Request message (as used in "stateless"  
DHCPv6) or the inclusion of the IA_PD code in an ORO, there has never
been any confusion in the past about the implementation of prefix
delegation.  We could write an errata for RFC 3633 if there is consensus
that such an update would be useful.

- Ralph



On Jul 21, 2008, at Jul 21, 2008,6:56 AM, Hemant Singh (shemant) wrote:

> Ralph,
>
> Thanks for the quick reply.  I too noticed the text related to Solicit
> in RFC3633 but that can be misinterpreted to be merely an example
> because even a 2-way Rapid Commit DHCPv6 could be used with IA_PD.
> Since we don't see a clear MUST NOT from RFC3633 or RFC3736, one may  
> say
> IA_PD is fine to use with stateless DHCPv6 as far as the interface has
> acquired a global address.
>
> Hemant
>
> -----Original Message-----
> From: Ralph Droms (rdroms)
> Sent: Monday, July 21, 2008 6:34 AM
> To: Hemant Singh (shemant)
> Cc: Ralph Droms (rdroms); Iljitsch van Beijnum; IPv6 Operations
> Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt
>
> Assigning a prefix through DHCPv6 is equivalent to assigning an  
> address,
> which is inherently stateful.
>
> Sections 11 and 12 of RFC 3633 specifies that IA_PD options are  
> carried
> in Solicit, Advertise, Request and Reply messages (as part of the
> initial RR<->DR message exchange).
>
> I note that RFC 3633 does not explicitly disallow the inclusion of an
> IA_PD in an Information-Request message (as used in "stateless"
> DHCPv6) or the inclusion of the IA_PD code in an ORO; however, the  
> text
> in RFC 3633 that describes the prefix delegation mechanism is, I  
> think,
> unambiguous in its description of how the IA_PD is used.
>
> - Ralph
>
> On Jul 20, 2008, at Jul 20, 2008,10:00 PM, Hemant Singh (shemant)  
> wrote:
>
>> For Iljitsch van Beijnum related to his question on whether IA_PD
>> could be asked of by stateless DHCPv6:
>>
>> Sorry one correction for this statement in the email below.
>>
>> "The Loopback interface would need to acquire a global IPv6 address
>> first using stateful DHCPv6 (a MUST, because SLAAC doesn't support
>> getting IA_PD).(a MUST, because SLAAC doesn't support getting  
>> IA_PD)."
>>
>> The Loopback interface may acquire the global IPv6 address using  
>> SLAAC
>
>> and not necessarily DHCPv6.  Then since the Loopback interface does
>> have a global address, then I believe it is permissible for stateless
>> DHCPv6
>> to get IA_PD by specifying the IA_PD option in the ORO?  We need to
>> check if RFC3633 explicitly prohibits asking for IA_PD by stateless
>> DHCPv6? Ole, what say you - thanks?
>>
>> Anyhow, the problem still remains that we expire the SLAAC address  
>> and
>
>> then reassign an address from IA_PD. Same old ugliness.
>>
>> Hemant
>>
>> -----Original Message-----
>> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
>> Behalf Of Hemant Singh (shemant)
>> Sent: Sunday, July 20, 2008 9:41 PM
>> To: Iljitsch van Beijnum
>> Cc: IPv6 Operations
>> Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt
>>
>> We are NOT adding any uRPF check feature to the CPE Router WAN on LAN
>> interface(s) nor any ping throttle feature for ping reqs or  
>> responses.
>> These are just topics being discussed.  uRPF was only given as an
>> example to say why CPE Router cannot work with just a link-local on
>> the WAN interface.
>>
>> We want to focus first on getting a complete set of requirements from
>> DSL folks and then see what does the draft shape out to be.  In our
>> -00 version of the draft, the draft was complete for cable deployment
>> because cable has completed docsis 3.0 standards for IPv6 as of two
>> years back and also an embedded CPE Router cable modem standard
>> completed in May 2007.
>>
>>
>> We have clearly said to this mailer early on, that till we get a
>> common consensus between DSL providers like AT&T, NTT, DSLForum folks
>> like David Miles, and a Mikael A., nothing in this draft is concrete.
>
>> Of course, I and Wes gave our cable recommendation to the DSL guys in
>> -00 version but they didn't like it.  Our cable recommendation in the
>> -00 version has nothing to do with IA_PD and stateless DHCPv6, or a
>> Loopback interface, or a WAN interface with only a link-local  
>> address.
>>
>> During the course of -01 and -02 versions we were attempting to fold
>> in requirements from DSL and that has caused some problems in the
>> draft.
>> The DSL requirements from NTT, AT&T, and a Mikael have been varied.
>> You
>> guessed correctly.  The Loopback interface cannot ask for IA_PD using
>> stateless DHCPv6 if the Loopback interface hasn't acquired a global
>> IPv6
>> address.  The RFC for stateless DHCPv6 in RFC3736 clearly says the
>> following in the Abstract section.
>>
>> [A node that uses stateless DHCP must have obtained its IPv6  
>> addresses
>
>> through some other mechanism, typically stateless address
>> autoconfiguration.].
>>
>> So the Loopback solution for DSL guys in our -02 version doesn't look
>> good even though Mikael A., and David Miles suggested this path to  
>> us.
>> As you can see we are still analyzing the solution and questioning
>> requirements.  The Loopback interface would need to acquire a global
>> IPv6 address first using stateful DHCPv6 (a MUST, because SLAAC
>> doesn't support getting IA_PD).  Also during stateful DHCPv6, the
>> IA_PD is doled out to the interface and the interface also gets an
>> IA_NA.  Since the interface already got a global address in the  
>> IA_NA,
>
>> then what's the point of assigning the interface an IPv6 address out
>> of the IA_PD?  So will one release the IA_NA, and then configure an
>> address on the interface from the IA_PD?  I don't like such
>> machinations.  Clearly, the DSL requirements are not flushed out yet
>> for us.
>>
>> Also, you can keep arguing about router vs. interface and who's
>> correct or not.  If the CPE Router needs a global address, the next
>> question folks will ask is what interface on the CPE Router does the
>> global address gets assigned to?  We are describing such details.
>>
>> Also, the virtual Loopback interface is in the same link-local domain
>> as the WAN interface.  Therefore any RA sent to the WAN interface has
>> to be also seen by the Loopback interface (CPE Router internals have
>> to take care of this).  So then it is legal for the Loopback to use
>> the RA seen by the WAN interface and the proceed to get a global IPv6
>> address for the Loopback address using SLAAC or DHCPv6.
>>
>> Hemant
>>
>>
>> -----Original Message-----
>> From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]
>> Sent: Sunday, July 20, 2008 3:39 PM
>> To: Hemant Singh (shemant)
>> Cc: IPv6 Operations
>> Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt
>>
>> On 20 jul 2008, at 15:45, Hemant Singh (shemant) wrote:
>>
>>>> 3. I disagree with the behavior suggested for "unnumbered" model. I
>>>> don't think a CPE router should automatically open up a maintenance
>>>> loopback interface just because it doesn't get a global IP address.
>>
>>> <hs>
>>
>> Would you PLEASE use normal quoting techniques? Reading email costs
>> enough time as it is without everyone doing stuff in their own
>> particular way so automation and habits don't work.
>>
>>> Not quite.  The unnumbered model is clearly saying the WAN interface
>>> only acquires on a link-local address.  But the WAN interface of the
>>> CPE Router has got to have a global IPv6 address.
>>
>> You are being extremely imprecise. That is one of the reasons your
>> draft is in such bad shape.
>>
>> The INTERFACE doesn't need a global address, but the ROUTER does.
>>
>>> So what choice does the
>>> CPE Router have but to automatically spawn a Loopback interface that
>>> will get assigned a global IPv6 address
>>
>> When you need to create a packet, use a source address from another
>> interface that you have, i.e. a LAN interface. I believe this is
>> explained in the base IPv6 specs. Or ask within your company about  
>> the
>
>> behavior of "ipv6 unnumbered ..."
>>
>>> (using SLAAC,
>>
>> Creating addresses using stateless autoconfig on an interface
>> different than the one where the RAs were received is very wrong.
>>
>>> DHCPv6
>>
>> Using DHCPv6 address configuration on a router makes no sense in my
>> opinion.
>>
>>> stateless DHCPv6 to acquire an IA_PD).
>>
>> I don't think prefix delegation is possible in the stateless version
>> of DHCPv6.
>>
>> On 20 jul 2008, at 15:51, Hemant Singh (shemant) wrote:
>>
>>> The draft clearly says what ICMPv6 errors are returned by the CPE
>>> Router, so it's not like the CPE Router is not responding to any
>>> ICMPv6
>>> request.
>>
>> Good.
>>
>>> Existing IPv4 routers do have a ping disable feature where the  
>>> router
>
>>> is configured to not respond to pings.
>>
>> You are again using imprecise terminology. What you mean is IPv4 CPEs
>> with NAT functionality. That has little to do with routing. For IPv6,
>> CPEs do have to be real routers and conform to normal router behavior
>> unless we specify exceptions.
>>
>> It is of course allowed to not return echo replies.
>>
>> However, since the router MUST generate other ICMPv6 messages under
>> other circumstances, not replying to pings doesn't make the router
>> invisible so there is little point in not returning ping replies.
>>
>>> I also said on this
>>> thread that if the CPE Router does respond to pings, the CPE Router
>>> needs to rate limit incoming ping reqs.
>>
>> You say that you want to rate limit INCOMING pings. (Which is useless
>> anyway because the LAN bandwidth is much higher than the WAN
>> bandwdith.) If you want to do this, it makes no sense to tie that to
>> whether or not ping replies are sent. For the router itself this is a
>> non-issue because the IPv6 specs mandate that ICMPv6 messages are  
>> rate
>
>> limited anyway.
>>
>> On 20 jul 2008, at 16:43, Hemant Singh (shemant) wrote:
>>
>>> Please see the complete uRPF thread that we discussed on this mailer
>>> -
>>
>>> they were emails between July 15 - 16th, 2008.
>>
>> I read it earlier today. It didn't make much sense to me. But now it
>> occurs to me that you actually want to run uRPF on the CPE itself. I
>> don't see how that's useful. What you want to do is filter out
>> outgoing packets on the WAN interface if they don't have a source
>> address that is either in the prefix delegated by the ISP or have the
>> router's own WAN address as a source address.
>>
>>
>>
>