On Mar 14, 2012, at 1:47 PM,
<[email protected]<mailto:[email protected]>>
<[email protected]<mailto:[email protected]>> wrote:
In 'compatibility' mode, if the CPE fails to enforce the
proper port range, the AFTR will perform a second level of NAT.
Med: If the ultimate target is to remove the NAT module from the AFTR, I would
see this compatibility mode as an implementation detail. BTW, why a CPE will
fail to restrict the port? I see at least two cases:
(1) want to grab more ports but this is not legitimate; I would vote for
discarding those packets instead of NATing them.
(2) the CPE does not support port-restriction: in that case why not use classic
DS-Lite instead of NATing twice.
This is a deployment issue. You have 3 variants of DS-Lite CPEs:
a) Basic 6333 DS-Lite, b) B4 translated DS-lite, and c) Stateless DS-Lite.
You want to be able able to accommodate all 3 variants from the same AFTR.
Re-Nating instead of dropping ensure that if a subscriber uses a variant b) when
he is provisioned to use port restricted, then traffic still flows.
In SD-Nat, the sd-CPE knows the external address via DHCPv4 over IPv6
Med: Ok, thanks. So for draft-penno-* two provisioning means are required
(compared to basic DS-Lite)
* DHCPv4 for IPv4 address allocation
* ICMP for port range configuration.
I must admit the rationale behind this choice is not clear to me.
You are right, the sdnat-02 does not provide enough rationale. We will have to
had text in the next version.
See my answer in the next question.
(*) 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.
Med: But the question is why ICMP-based method is needed? Why not using
port-restricted DHCPv4 options for instance?
1) - we would have to define the DHCP port option. Not difficult but same
amount of work as defining a new ICMP type.
2) - with the ICMP message, the ISP can change the port range without having to
wait for the lease time of the DHCP option to expire.
This allows for more flexibility in micro-managing ports.
3) - if we use a DHCP option, the client has to proactively ask for it. If it
does not, it will think it has the full IP address. That leads to situations
that may be difficult to debug, as the customer will not understand why some
TCP session works and some don't, the root cause being that the CPE does not
have any feedback from the NAT in the AFTR
4) - so we'll need a new ICMP message anyway to signal the CPE that something
is wrong if/when it sends packets outside of the range.
The advantage of the DHCP option is that the CPE does not need to send the
packet with src port 0 at regular intervals, this is all taken care by the DHCP
machinery. IMHO, this does not outweight the issues mentioned above, especially
3) & 4).
Alain
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
