Qi, >>> 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.
the main concern of MAP-DHCP is to provision the tunnel, i.e. the link-layer. stateful DHCPv4 is not a possibility with MAP. I do agree that we could have a paragraph on "other configuration information". >> 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. please read the map-dhcp draft. there are separate container options for the 3 mechanisms that map-dhcp include. cheers, Ole
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
