[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt
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.
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.
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
> 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.
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:email@example.com] 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
> The DSL requirements from NTT, AT&T, and a Mikael have been varied.
> guessed correctly. The Loopback interface cannot ask for IA_PD using
> stateless DHCPv6 if the Loopback interface hasn't acquired a global
> 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
> 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.
> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:firstname.lastname@example.org]
> 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.
> 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.
> Using DHCPv6 address configuration on a router makes no sense in my
>> 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
>> 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.