In your previous mail you 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?
=> there is one but:
- it translates only port numbers following an algorithm
- the NAT is not strictly required: one can imagine to assign
directly to a CPE its port range as it is visible from the Internet
(note: 1- it should be not what we want as it makes CPEs trivial
to track, 2- it doesn't remove the mandatory check on source ports
in the from CPE to the Internet way)
> (*) Question 2: If yes, is there any reason why you want to
> maintain that second NAT?
=> I can see at least 2 reasons:
- make CPE simplers (only applications which need to know what is a port
number seen from the Internet side have to enter into the second NAT
details, i.e., typically the PCP (/UPnP iGD/NAT-PMP/...) server on the CPE)
> (*) 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.
=> my read of the SD-NAT mechanism is the public IP address is the same
at each side of the SD-CGN.
> (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):
=> but the ICMP-based solution is deeply broken so is it a real
advantage?
> (*) Question 4: Given this list, is there really a need for the
> proposed ICMP-based solution?
=> see previous item
> (*) 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.
=> no such specific:
- it makes the reasonable assumption than IPv4 addresses are assigned
using DHCPv4
- it states "DS-Lite" so there is no direct IPv4 available
- so IMHO the question is more about the DHCPv4-over-IPv6 application
and is more for the DHC WG (BTW please don't bounce this issue between
the two WGs, my idea is more to make a point about DHCPv4-over-IPv6
itself)
> 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?
=> if they are the same the answer is easy
> (3) draft-penno-* advocates it is deterministic but this feature can
> be enforced in any IPv4 address sharing technique:
=> BTW we need a better definition of "deterministic". My proposal
is it means the mapping follows an algorithm (and it is the case on
the SD-CGN, BTW not on the SD-CPE).
> (*) Question 6: Is there any particular reason draft-penno-* does
> not mention draft-donley-behave-deterministic-cgn?
=> too many drafts...? More seriously I have more concerns about
too simple algorithms deployed in the SD-CGN, for instance the:
[1024...xxx] <-> [N...<N-1024+xxx] where p' = p + N - 1024
is good for tests or demos but makes CPEs too easy to trace,
I prefer what draft-tsou-softwire-port-set-algorithms-analysis calls GMA
(still trivial to implement and to use but harder to trace).
Regards
[email protected]
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
