Subject: FW: I-D Action:draft-wbeebee-ipv6-cpe-router-00.txt

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Tue, 8 Jul 2008 10:25:30 -0400

Brian,

Thanks for the comments. Please see in line below between comments <wb>
and </wb>. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brian E Carpenter
Sent: Monday, July 07, 2008 7:17 PM
To: IPv6 Operations
Subject: Re: I-D Action:draft-wbeebee-ipv6-cpe-router-00.txt

Hi, some comments on other points.

> 5.3.  Acquire IPv6 address and other configuration parameters

I suggest that if address acquistion by DHCPv6 fails, there should be a
(configurable) option to discover a 6to4 relay. CPE routers were in fact
a target when 6to4 was designed.
It only needs a few lines and a reference to RFC 3056 and 3068.

<wb>
Sorry, we don't agree. Also times have changed since 2001 when RFC3056
of RFC3068 were authored. This CPE Router can also be deployed in a
cable deployment which is IPv6 ready between the home and aggregator
(CMTS). Since the CPE Router initiated DHCPv6, the Service Provider
router in the upstream has issued an RA to the CPE Router. Therefore if
DHCPv6 fails, something is wrong in the Service Provider network for
provisioning. Of course, there could be a malformed DHCPv6 message from
the CPE Router as well - but that's not the point. In a totally IPv6
ready network it doesn't make sense for the CPE Router to fall back to
discover any 6to4 relay. If DHCPv6 fails in such a deployment, the
Router's IPv6 functionality is dead. For DSL, which is not an IPv6 ready
network yet, one plan I have seen from industry is softwires. The
softwire creates a L2TP tunnel to carry ipv6 traffic in a ipv4 tunnel:

http://tools.ietf.org/html/draft-ietf-softwire-hs-framework-l2tpv2-08

In the softwire case, the L2TP tunnel is already created before DHCPv6
is initiated, so if DHCPv6 fails, then even this deployment has IPv6
services dead. Discovering a 6to4 relay is adding extra states to the
state machine of the CPE Router. We are very careful adding any extra
state machine to the CPE Router. We could configure whether you want
6to4 tunnel or DHCPv6 before the state machine for either DHCPv6 or 6to4
starts.  That would simplify the state machine. 
</wb>

Also I suggest that there should be a configurable option to generate
and support a ULA prefix. Again, a few lines and a reference to RFC
4193.

<wb>
Please see the -01 draft where we discuss assignment of ULA to LAN
interface(s) of the CPE Router.
</wb>

> 6.  IPv6 Data forwarding
...
>                                       Each protocol that the CPE
>    Router can forward packets for must have a separate routing table.

I've read that sentence several times and can't understand it. Do you
simply mean that the IPv6 table is separate from IPv4?

<wb>
Yes.  This statement is kind of obvious and probably doesn't need to be
stated.
</wb>

...
>                         Before forwarding a packet
>    in any direction from CPE router, the CPE Router will perform a MAC
>    rewrite operation that rewrites the source L2 address of the packet
>    with CPE Router's WAN or LAN interface MAC address.  

I also don't understand that sentence. Surely a router moves an L3
packet from one L2 interface to another, and removing and creating
L2 headers is nothing to do with routing as such?

<wb>
Yes, but it's only a router that performs a mac rewrite. A bridge or
switch does not do that. That is why such text exists in our draft. We
would like to keep it. 
</wb>

> 7.1.  Path MTU Discovery Support
> 
>    GRE tunnels, such as 6-to-4 tunnels (which may be terminated on the
>    CPE Router),

This is confusing. 6to4 (no hyphens) refers to RFC 3056 and has nothing
to do with GRE. In fact any kind of Protocol 41 tunnel can interfere
with MTU too - do you expect a typical CPE to support generic Protocol
41 tunnels? I think that by '6-to-4' you probably mean "IPv6 in IPv4"?

<wb>
Sorry, we didn't use correct terminology. We did mean IPv6 in IPv4.
We'll change the text to say IPv6 in IPv4.  
</wb>

> 8.  Quality Of Service(QoS)
> 
>    The CPE router may map the IPv6 Traffic Class field from [RFC2460]
to
>    individual queues of different priority to provide differentiated
>    classes of service for traffic either destined to the LAN or WAN
>    interfaces (e.g. for IPTV service).

You shouldn't use the word 'priority' because the diffserv model is not
about priority. Better to use 'behavior' plus a reference to RFC 2474.
In fact, the whole thing can be expressed as

  The CPE router MAY support differentiated services [RFC2474].

<wb>
Great suggestion. We will take it.
</wb>

Thanks.

Wes & Hemant

     Brian

---

From: Antonio Querubin <[email-masked]>
Date: Tue, 8 Jul 2008 06:49:54 -1000 (HST)

> switch does not do that. That is why such text exists in our draft. We

Is 'rewriting' actually a valid description of what's happening?  Suppose 
one of those interfaces has no MAC?

Antonio Querubin
whois:  AQ7-ARIN

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Tue, 8 Jul 2008 12:55:54 -0400

We could say instead:
"The CPE router will convert the packet from one L2 domain to another
(e.g. through MAC rewrite) when the packet crosses L2 domains (e.g. from
WAN to LAN or LAN to WAN)". 

- Wes

-----Original Message-----
From: Antonio Querubin [mailto:[email-masked]] 
Sent: Tuesday, July 08, 2008 12:50 PM
To: Wes Beebee (wbeebee)
Cc: [email-masked]; [email-masked]
Subject: Re: FW: I-D Action:draft-wbeebee-ipv6-cpe-router-00.txt

> </wb>

Is 'rewriting' actually a valid description of what's happening?
Suppose one of those interfaces has no MAC?

Antonio Querubin
whois:  AQ7-ARIN

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Jul 2008 16:02:40 +1200

On 2008-07-09 02:25, Wes Beebee (wbeebee) wrote:
> Router's IPv6 functionality is dead. 

The key statement here is "in such a deployment". What about a CPE
that is sold off the shelf to a user whose ISP knows nothing
about IPv6? What is the harm in a CPE that can implement 6to4?

It certainly is a MAY implement that MUST be configurable on or
off, but if a CPE vendor wishes to add this code, why not?

> For DSL, which is not an IPv6 ready

Sure. That will be more for hobbyists than for random citizens, but I
think that's where 6to4 should play.
> switch does not do that. That is why such text exists in our draft. We

But it's the wrong conceptual model. Even if what you actually do is
tweak an existing Ethernet header, logically you are decapsulating the L3
packet and re-encapsulating it. Your description makes it sound like
an L2 NAT instead of a perfectly normally forwarding action.

    Brian

---

From: Gert Doering <[email-masked]>
Date: Wed, 9 Jul 2008 10:12:52 +0200

Hi,

> WAN to LAN or LAN to WAN)". 

This should just be dropped.

It's obvious that a router needs to do that, and not specific to "IPv6 CPE"
- and this is just distracting the reader with specific L2 details that
have no relevance to the *IPv6* part.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  110584

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 9 Jul 2008 14:17:46 -0400

Ok, we will remove the text from our draft since its obvious to folks.

Thanks.

Hemant & Wes. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Gert Doering
Sent: Wednesday, July 09, 2008 4:13 AM
To: Wes Beebee (wbeebee)
Cc: Antonio Querubin; [email-masked]; [email-masked]
Subject: Re: FW: I-D Action:draft-wbeebee-ipv6-cpe-router-00.txt

Hi,

On Tue, Jul 08, 2008 at 12:55:54PM -0400, Wes Beebee (wbeebee) wrote:
> (e.g. through MAC rewrite) when the packet crosses L2 domains (e.g. 
> from WAN to LAN or LAN to WAN)".

It's obvious that a router needs to do that, and not specific to "IPv6
CPE"
- and this is just distracting the reader with specific L2 details that
have no relevance to the *IPv6* part.

Gert Doering
        -- NetMaster

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A.
Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 9 Jul 2008 16:21:08 -0400

Brian,

You said: 

"The key statement here is "in such a deployment". What about a CPE that
is sold off the shelf to a user whose ISP knows nothing about IPv6? What
is the harm in a CPE that can implement 6to4?

It certainly is a MAY implement that MUST be configurable on or off, but
if a CPE vendor wishes to add this code, why not?"

Even a standalone CPE router sold off the shelf for IPv4 currently needs
manual configuration for either DHCP or PPPOE, PPTP, L2TP, etc. for the
WAN interface - it's not that plug and play. However, your point is
valid. We will mull over this request and see what we can do.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brian E Carpenter
Sent: Wednesday, July 09, 2008 12:03 AM
To: Wes Beebee (wbeebee)
Cc: [email-masked]
Subject: Re: FW: I-D Action:draft-wbeebee-ipv6-cpe-router-00.txt

On 2008-07-09 02:25, Wes Beebee (wbeebee) wrote:
> Brian,
> 
> Thanks for the comments. Please see in line below between comments 
> <wb> and </wb>.
> 
> (configurable) option to discover a 6to4 relay. CPE routers were in 
> fact a target when 6to4 was designed.

> provisioning. Of course, there could be a malformed DHCPv6 message 
> from the CPE Router as well - but that's not the point. In a totally 
> IPv6 ready network it doesn't make sense for the CPE Router to fall 
> back to discover any 6to4 relay. If DHCPv6 fails in such a deployment,

> the Router's IPv6 functionality is dead.

The key statement here is "in such a deployment". What about a CPE that
is sold off the shelf to a user whose ISP knows nothing about IPv6? What
is the harm in a CPE that can implement 6to4?

It certainly is a MAY implement that MUST be configurable on or off, but
if a CPE vendor wishes to add this code, why not?

> 6to4 tunnel or DHCPv6 before the state machine for either DHCPv6 or 
> 6to4 starts.  That would simplify the state machine.

> Yes.  This statement is kind of obvious and probably doesn't need to 
> be stated.
> </wb>
> 
> ...

But it's the wrong conceptual model. Even if what you actually do is
tweak an existing Ethernet header, logically you are decapsulating the
L3 packet and re-encapsulating it. Your description makes it sound like
an L2 NAT instead of a perfectly normally forwarding action.

    Brian

> This is confusing. 6to4 (no hyphens) refers to RFC 3056 and has 
> nothing to do with GRE. In fact any kind of Protocol 41 tunnel can 
> interfere with MTU too - do you expect a typical CPE to support 
> generic Protocol
> You shouldn't use the word 'priority' because the diffserv model is 
> not about priority. Better to use 'behavior' plus a reference to RFC
2474.