Hi Med, see inline response to your questions wrt sd-nat-02
On Mar 13, 2012, at 10:58 AM,
<mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>>
<mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> 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
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
