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

["Hemant Singh (shemant)" <shemant@cisco.com>]

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: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
Behalf Of Brian E Carpenter
Sent: Wednesday, July 09, 2008 12:03 AM
To: Wes Beebee (wbeebee)
Cc: v6ops@ops.ietf.org
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>.
> 
> -----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
> 
> 
>