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.