Hi Cong, Please see inline.
Cheers, Ian On 22 Oct 2013, at 14:42, Cong Liu <[email protected]> wrote: > Dear Tom and all, > > I think this discussion is significant. > > 2013/10/18 Tom Taylor <[email protected]> > (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. 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. > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
