[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.