Hi Francis,
Please see inline, and sorry if they've been discussed ever :)
Looking forward to ur reply~
Best Regards !
Qi Sun
From: Francis Dupont
Date: 2012-03-14 20:44
To: Qiong
CC: Softwires WG; draft-cui-softwire-b4-translated-ds-lite;
draft-penno-softwire-sd...@tools.ietf.org
Subject: Re: [Softwires] draft-penno-softwire-sdnat vs.
draft-cui-softwire-b4-translated-ds-lite
In your previous mail you wrote:
> > 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)
> >
> [Qiong] Thanks for clarification. It seems this is not mentioned when to
> adopt and how to process the second NAT in current version of sd-nat. But
> still, I would prefer a solution without double-NAT.
=> my answer is simple:
1- it is technically possible but IMHO should not be deployed in the real
world.
[Qi] I failed to catch your idea. IMHO the NAT in the port-restricted CPE
should filter the
packets of which the port number is out of the assigned range. And such packets
is ok to
be discarded by the CPE. So will you please give some descriptions on this
point?
2- one can avoid only the second NAT itself, not the packet reassembly for
instance.
3- the second NAT is a pretty simple one and is stateless (i.e., you can drop
the CGN box and hotplug a replacement box with the same config: customers
should see only the packets dropped during the operation. BTW we have a
plan to show this at the next IETF meeting).
> > => but the ICMP-based solution is deeply broken so is it a real
> > advantage?
> >
> [Qiong] In draft-cui-softwire-b4-translated-ds-lite, we have described the
> "ICMP processing" in section 10. And we have verified that it works fine in
> all ICMP-based protocols, e.g. ping, tracert, etc. There is no problem here.
=> my comment was about the ICMP-base solution for the configuration in
Reinaldo Penno's I-D. Of course I have no concern about raising admin prohib
ICMPs when a port out-of-range packet is filtered (in fact it is a great idea).
For the ICMP echo service you can map it using the ID as the (source) port,
it works well but if you'd like to use this from the Internet side you need
a modified ping where you can set the ID to use (I can provide one if you want
to try: IMHO it is better to be able to ping SD-CPEs and not only the SD-CGN).
> > > 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)
> >
> [Qiong] I still think it is deployment-specific. For operators who perfer
> to deploy PCP solution, it is nature for them to adopt PCP-base or
> PCP-extension (pcp-natcoord). For operators who would like to deploy
> DHCPv4-over-IPv6, port-range can be assigned in this way.
=> I misunderstood your concern: in fact you prefer something which provides
the whole config, not only the IPv4 address. So the issue is not the 2.1 but
the 2.1 and 2.2 (i.e., DHCPv4 over IPv6 for the external address, and ICMP
for the port range) together, and you already know what I think about 2.2.
[Qi] Using ICMP for the port range is a new idea AFAIK. However, in order to
get the info
of the min & max port number, it is needed to look up the per-subscriber
mapping table
which may be huge. I've no idea if it's ok for the ICMP process to do that.
And I'm thinking whether it's necessary to make it clear about how to get the
min & max
port number in the draft.
> [Qiong] Since it is a stateless solution, I also prefer the GMA algorithm
> which has been discusses widely in the WG.
=> yes, it has many advantages. But to come back to the first point, it is
for the second NAT (:-)!
Regards
francis.dup...@fdupont.fr
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
