Hi Alain, It's a little confusing now. Let me try to get things clear.
So the sd-nat-02 is not quite similar to the earlier version, the mechanism somehow changes. In my understanding, now the principle of the mechanism is similar to the lightweight 4over6 draft, but I may miss something here. My question is, how is it stateless or deterministic, and how is IPv6 anycast for multiple AFTRs working? Seems the draft is suggesting that we put an identical profile on each AFTR, the content of which is the mapping between IPv6 address and IPv4 address+port range for all the CPEs (And of course, we can try to find some protocol to synchronize the mapping automatically). Did I get this correctly? 2012/3/14 Alain Durand <[email protected]>: > Hi Med, see inline response to your questions wrt sd-nat-02 > > On Mar 13, 2012, at 10:58 AM, > <[email protected]<mailto:[email protected]>> > <[email protected]<mailto:[email protected]>> wrote: > > > > (*) Question 1: It is not clear in text if there is a second NAT > in the AFTR or not. Could you please confirm/infirm a second NAT > is present? > > > in sd-nat, packets originated by an sd-CPE will be 'shaped' to use the > correct IPv4 address and port by the CPE before being encapsulated in IPv6. > In that scenario, the AFTR decapsulate the traffic, check IPv4 address & port > range are indeed assigned to that IPv6 user, then forward the packet. There > is only one level of NAT, done by the CPE > > In 'compatibility' mode, if the CPE fails to enforce the proper port range, > the AFTR will perform a second level of NAT. > > (*) Question 2: If yes, is there any reason why you want to > maintain that second NAT? > > > in SD-nat, the 2nd NAT is only there to enable 'legacy' DS-Lite CPEs or > DS-lite + B4 translated CPEs to interoperate with stateless DS-Lite CPEs. > > > (*) Question 3: If the public IP address assigned by the AFTR is > not known to the port-restricted CPE, some applications may fail > (referral). How the CPE will make a distinction between the > external IP address to be assigned in the WAN and the one used in > the AFTR? If UPnP is used, the WAN IP address should not be > returned. > > In SD-Nat, the sd-CPE knows the external address via DHCPv4 over IPv6 > > > (2) Unlike draft-penno-*, draft-cui-* does not mandate any proffered > provisioning means for port ranges; a list of alternatives is > provided in draft-cui-* without any preference (this is deployment- > specific): > > o DHCPv4: the DHCPv4 protocol should be extended to support port-set > allocation > [I-D.bajko-pripaddrassign<http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-05#ref-I-D.bajko-pripaddrassign>]. > Besides, the DHCP message > should send to the concentrator over IPv6. The concentrator can > be the DHCP server or DHCP relay > agent[I-D.ietf-dhc-dhcpv4-over-ipv6]. > > o PCP[I-D.ietf-pcp-base]: an initiator can launch multiple PCP > requests simultaneously to acquire a number ports within the same > IPv4 address, or use > [I-D.tsou-pcp-natcoord<http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-05#ref-I-D.tsou-pcp-natcoord>] > for one-time port-set > allocation. > > o DHCPv6: the DHCPv6 protocol should be extended to support port-set > allocation > [I-D.boucadair-dhcpv6-shared-address-option<http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-05#ref-I-D.boucadair-dhcpv6-shared-address-option>]. > > o IPCP: IPCP should be extended to carry the port-set. > [RFC6431<http://tools.ietf.org/html/rfc6431>] > gives an example. > > (*) Question 4: Given this list, is there really a need for the > proposed ICMP-based solution? > > > IMHO, not specifying the technology to get pot range and living this to > implementation is a serious shortcoming. > We need to standardize one method. > > > (*) Question 5: draft-penno-* says: "A stateless DS-Lite CPE MUST > implement the DHCPv4 client relay option defined in [I-D.ietf-dhc- > dhcpv4-over-ipv6] to learn is external IPv4 address.". > > Question 5-1: Why "MUST"? IMHO, this is deployment-specific. > > > Same as above, we need to have one common technology that is implemented by > everyone. This is the only way > to guaranty interoperability. > > > > Question 5-2: By "external IPv4 address", do you mean the > address to be assigned in the AFTR (if any)? or the one to be > used in the WAN interface of the CPE? > > > The IPv4 address to put as src address of v4 traffic by the CPE before > encapsulating in IPv6 and sending to AFTR. > > > > (3) draft-penno-* advocates it is deterministic but this feature can > > be enforced in any IPv4 address sharing technique: > > (*) Question 6: Is there any particular reason draft-penno-* does > not mention draft-donley-behave-deterministic-cgn? > > > No > > Alain. > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
