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

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

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>. 
> 
> -----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. 

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
> 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. 

Sure. That will be more for hobbyists than for random citizens, but I
think that's where 6to4 should play.
> </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>

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

> 
>> 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
> 
> 
>