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

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

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.
>
>
>