Re: [Softwires] Thoughts on provisioning and universal CPE

Dear Ian,

Please see inline.

On 2013-10-22, at 下午10:40, Ian Farrer wrote:

> Hi Cong,
> 
> Please see inline.
> 
> Cheers,
> Ian
> 
> On 22 Oct 2013, at 14:42, Cong Liu <gnocuil@gmail.com> wrote:
> 
>> Dear Tom and all,
>> 
>> I think this discussion is significant.
>> 
>> 2013/10/18 Tom Taylor <tom.taylor.stds@gmail.com>
>> (1) DHCP Provisioning of IPv4 Options
>> ====================================
>> 
>> The conclusion out of Berlin is that the best general solution to provisioning of IPv4 and transition-specific options is to use DHCPv4 over DHCPv6 as documented in draft-ietf-dhc-dhcpv4-over-dhcpv6-01.txt. The authors of draft-ietf-softwire-map-dhcp-05.txt argue that that document is sufficient to meet the needs of MAP, but it is not a general solution and leaves the other techniques uncovered.
>> 
>> [Cong] I agree with this conclusion that DHCPv4 over DHCPv6 shoud be used as the IPv4 provisioning protocol in IPv6 network.
>> I think it's clear that DHCPv4 is designed for IPv4 address provisioning, and DHCPv6 is designed for IPv6 address provisioning. I don't understand what the benefit is to use DHCPv6 for IPv4 address provisioning.
> 
> [ian] From discussions in the DHC WG meetings in Atlanta/Orlando, I understood that there was general agreement that if ONLY IPv4 address / port set / MAP rules were necessary, for static reserved addresses, then provisioning this over DHCPv6 was acceptable. This is from my memory of the discussions, there was no poll taken.

[Qi] This should be documented as a statement in the map-dhcp to specify the case where to use DHCPv6 options for IPv4 allocation or not, if map-dhcp intends to be a 'Softwire 46 DHCP Options' document.

> However, the MAP-DHCP draft covers this case. 
> 
> But, if dynamic v4 addresses or any other DHCPv4 options were necessary, then DHCPv4 over DHCPv6 would be the way of providing this. The v4-configuration document evaluates approaches against these requirements which is why it reaches the conclusion that it does.
> 
> So, I see that both can co-exist. They are solutions to meet different requirements and have their own set of limitations.
> 
> 
>>  
>> (4) Summary of Provisioned Information
>> =====================================
>> 
>> Common to multiple methods
>> --------------------------
>> 
>> Every method requires signalling of the IPv6 tunnel endpoint addresses at the CPE and the BR. It is assumed that this is done as a preliminary step, as illustrated in draft-ietf-softwire-public-4over6-10.txt Figure 2. That document assumes the provisioning of both addresses is done by DHCPv6, if it is done by DHCP at all.
>> 
>> Note that RFC 6334 provides the AFTR-Name option, which is an FQDN.
>> 
>> [Cong] map-dhcp-05 defines a new DHCPv6 option OPTION_S46_BR to provide BR/lwAFTR address. The draft requires both MAP-E and lw4o6 to use this option.
> 
> [ian] map-dhcp-05 only describes a DHCPv6 option for provisioning MAP/lw4o6. It doesn't make any requirements that clients implement the option. Any provisioning requirements are the other way round (i.e. the softwire mechanism draft has a normative reference to the draft that describes provisioning).
> 
>> If a unified tunnel-end option is needed, OPTION_AFTR_NAME in RFC6334 should be used. If this option is not good enough, we should update it.
>> If OPTION_S46_BR is not going to cover DS-Lite, it should not include lw4o6 either. Then we should define seperate options for each mechanism.
>> http://tools.ietf.org/html/draft-sun-softwire-lw4over6-dhcpv6-00 describes such scenario. 
>> 
> [ian] I don't see a requirement for a unified tunnel-endpoint. Quite the reverse, in fact. If you have several tunnel endpoints for different tunnelling methods, then you probably need a way of separating them so that you can direct client traffic to the right tunnel concentrator.
> We tried re-using OPTION_AFTR_NAME, but this gives you the problem of how to identify RFC6333 tunnel clients from other softwire clients so that you can route their traffic accordingly. An existing DS-Lite client does not support OPTION_S46_BR and any practical solution for new softwire mechanisms must be backwards compatible with existing ds-lite clients.

[Qi] IMO, what you said falls into Cong's second 'if': lw4o6, map-e, ds-lite are different tunnel mechanisms, so that different DHCPv6 options for signaling of tunnel concentrator's v6 address are necessary. Or the client would be not able to identify which tunnel concentrator it should connect to.

Best Regard,
Qi

> 
>> 
>> Light-Weight 4over6
>> -------------------
>> 
>> An object to specify the assigned port set is required. This would be carried via DHCPv4overDHCPv6.
>> 
>> [Cong] I agree and think it's a consensus that the recommended provisioning mechanism for lw4o6 is DHCPv4 over DHCPv6, not DHCPv6.
>> 
>> Best Regards, 
>> Cong
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
> 
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires