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

[Francois-Xavier Le Bail <fx.lebail@yahoo.com>]

You say "Also, the virtual Loopback interface is in the same link-local domain as the WAN interface."

I don't understand your architecture. bridge? no bridge?

Can you make a diagram of the WAN side ?

Francois-Xavier

--- On Sun, 7/20/08, Hemant Singh (shemant) <shemant@cisco.com> wrote:

> From: Hemant Singh (shemant) <shemant@cisco.com>
> Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt
> To: "Iljitsch van Beijnum" <iljitsch@muada.com>
> Cc: "IPv6 Operations" <v6ops@ops.ietf.org>
> Date: Sunday, July 20, 2008, 9:41 PM
> 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.