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

["Wes Beebee (wbeebee)" <wbeebee@cisco.com>]

Brian,

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

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] 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