Subject: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite

From: <[email-masked]>
Date: Tue, 13 Mar 2012 10:58:45 +0100

Hi Reinaldo, all,

I read the updated version of draft-penno-softwire-sdnat. I like this new version. Below some questions for clarification:

   (1) draft-penno is converging to what is documented in
   draft-cui-softwire-b4-translated-ds-lite:

      (*) 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?

      (*) Question 2: If yes, is there any reason why you want to
      maintain that second NAT?

      (*) 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.

   (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?

      (*) 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.

         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?

   (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?

Cheers,
Med

---

From: Francis Dupont <[email-masked]>
Date: Tue, 13 Mar 2012 17:55:35 +0100

>        in the AFTR or not.  Could you please confirm/infirm a second NAT

=> 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)
  
>        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)

>        the AFTR?  If UPnP is used, the WAN IP address should not be

=> my read of the SD-NAT mechanism is the public IP address is the same
at each side of the SD-CGN.

>     provided in draft-cui-* without any preference (this is deployment-

=> but the ICMP-based solution is deeply broken so is it a real
advantage?

>        proposed ICMP-based solution?

=> see previous item

>           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)

>           used in the WAN interface of the CPE?

=> if they are the same the answer is easy

>     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).

>        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-masked]

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 13 Mar 2012 15:19:26 -0500

> (still trivial to implement and to use but harder to trace).

I agree. GMA is defined here, btw -
http://tools.ietf.org/html/draft-mdt-softwire-mapping-address-and-port-0
2#section-4.1

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Francis Dupont
> Sent: Tuesday, March 13, 2012 12:56 PM
> To: [email-masked]
> Cc: Softwires WG; draft-cui-softwire-b4-translated-ds-lite;
draft-penno-
> [email-masked]
> Subject: Re: [Softwires] draft-penno-softwire-sdnat
vs.draft-cui-softwire-b4-
> translated-ds-lite
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Qiong <[email-masked]>
Date: Wed, 14 Mar 2012 07:50:27 +0800

Hi Francis,

Thanks for your reply. Please see inline.

>    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.

> => but the ICMP-based solution is deeply broken so is it a real
[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.

>  the two WGs, my idea is more to make a point about DHCPv4-over-IPv6
[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.

> (still trivial to implement and to use but harder to trace).
[Qiong] Since it is a stateless solution, I also prefer the GMA algorithm
which has been discusses widely in the WG.

Best wishes

Qiong

---

From: GangChen <[email-masked]>
Date: Wed, 14 Mar 2012 13:39:42 +0800

>   details, i.e., typically the PCP (/UPnP iGD/NAT-PMP/...) server on the

However, the draft seems give people impression there is only one NAT
at CPE(i.e. 2.3.  Stateless DS-Lite CPE operation) and AFTR is
responsible for decapsulation and IPv4 package validation.  Did I miss
something?

BRs

Gang

---

From: <[email-masked]>
Date: Wed, 14 Mar 2012 07:42:06 +0100

Hi Francis,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] 
> Envoyé : mardi 13 mars 2012 17:56
> À : BOUCADAIR Mohamed OLNC/NAD/TIP
> Cc : [email-masked]; Softwires WG; 
> draft-cui-softwire-b4-translated-ds-lite
> Objet : Re: [Softwires] draft-penno-softwire-sdnat vs. 
> draft-cui-softwire-b4-translated-ds-lite 
> 

Med: Ok, thanks. But this is not clear in the -02 of draft-penno-*.

>    directly to a CPE its port range as it is visible from the Internet

Med: Agree.

>     in the from CPE to the Internet way)

Med: I failed to get your first point. Could you please clarify? Thanks.

>   details, i.e., typically the PCP (/UPnP iGD/NAT-PMP/...) 

Med: applications using referral need to know the external IP address. I failed to see why this is simpler compared to draft-cui-*.

> at each side of the SD-CGN.

Med: This is not clear in -02 of the draft-penno-*.

>  - it makes the reasonable assumption than IPv4 addresses are assigned

Med: It is not "reasonable" when you don't have a DHCPv4 server but use PCP for instance. 

> => too many drafts...?

Med: I think it is fair to cite draft-donley-*.

 More seriously I have more concerns about
> I prefer what 
> draft-tsou-softwire-port-set-algorithms-analysis calls GMA

Med: We don't have the constraint of MAP so I would not exclude pseudo-random port set algos (see http://tools.ietf.org/html/draft-tsou-softwire-port-set-algorithms-analysis-01#section-3.3)

---

From: <[email-masked]>
Date: Wed, 14 Mar 2012 07:45:47 +0100

Re-,

Thanks Rajiv for the pointer. 

BTW unlike the constraints we have in MAP (e.g., the bits forming PSID must be adjacent), draft-cui-* and the like can use pseudo-random algorithms to generate port ranges. 

Cheers,
Med

> De : Rajiv Asati (rajiva) [mailto:[email-masked]] 
> Envoyé : mardi 13 mars 2012 21:19
> À : Francis Dupont; BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]
> Cc : Softwires WG; draft-cui-softwire-b4-translated-ds-lite; 
> [email-masked]
> Objet : RE: [Softwires] draft-penno-softwire-sdnat 
> vs.draft-cui-softwire-b4-translated-ds-lite
> 
> > >        (*) 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:
> > >        (*) Question 3: If the public IP address assigned 
> by the AFTR
> is
> > >        (*) Question 5: draft-penno-* says: "A stateless 
> DS-Lite CPE
> MUST
> > >           address to be assigned in the AFTR (if any)? or 
> the one to
> be
> > >     (3) draft-penno-* advocates it is deterministic but 
> this feature
> can
> > >        (*) Question 6: Is there any particular reason 
> draft-penno-*
> does

---

From: <[email-masked]>
Date: Wed, 14 Mar 2012 07:49:36 +0100

Dear Qiong,

Please see inline.

Cheers,
Med

________________________________
De : Qiong [mailto:[email-masked]]
Envoyé : mercredi 14 mars 2012 00:50
À : Francis Dupont
Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; Softwires WG; draft-cui-softwire-b4-translated-ds-lite; [email-masked]
Objet : Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite

=> 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.

[Med] I know it is confusing but these are two distinct issues. draft-penno-* defines a new method using ICMP to learn ports. Please refer to http://tools.ietf.org/html/draft-penno-softwire-sdnat-02#section-5

---

From: Alain Durand <[email-masked]>
Date: Wed, 14 Mar 2012 04:10:39 -0700

Hi Med, see inline response to your questions wrt sd-nat-02

On Mar 13, 2012, at 10:58 AM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

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.

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.

In SD-Nat, the sd-CPE knows the external address via DHCPv4 over IPv6

IMHO, not specifying the technology to get pot range and living this to implementation is a serious shortcoming.
We need to standardize one method.

Same as above, we need to have one common technology that is implemented by everyone. This is the only way
to guaranty interoperability.

The IPv4 address to put as src address of v4 traffic by the CPE before encapsulating in IPv6 and sending to AFTR.

No

Alain.

---

From: Peng Wu <[email-masked]>
Date: Wed, 14 Mar 2012 20:07:34 +0800

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?

---

From: Francis Dupont <[email-masked]>
Date: Wed, 14 Mar 2012 13:44:11 +0100

>  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.
 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).

>  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).

>  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.

>  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

---

From: <[email-masked]>
Date: Wed, 14 Mar 2012 13:47:54 +0100

Re-,

Thanks Alain for the answers. Please see inline.

Cheers,
Med

> De : Alain Durand [mailto:[email-masked]] 
> Envoyé : mercredi 14 mars 2012 12:11
> On Mar 13, 2012, at 10:58 AM, 
> <[email-masked]<mailto:mohamed.boucadair@orange.
> com>> 
> <[email-masked]<mailto:mohamed.boucadair@orange.
> com>> wrote:
> 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

Med: Ok, got it. This is the same as per draft-cui-*.

> 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.
 
> 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.

> IMHO, not specifying the technology to get pot range and 
> living this to implementation is a serious shortcoming.

Med: But the question is why ICMP-based method is needed? Why not using port-restricted DHCPv4 options for instance?

---

From: Francis Dupont <[email-masked]>
Date: Wed, 14 Mar 2012 14:34:22 +0100

>  responsible for decapsulation and IPv4 package validation.  Did I miss

=> yes, the SD-CGN (the SD-AFTR with DS-Lite) runs a second NAT but
only on port (vs. address and port) and following algorithm (aka stateless).

Regards

PS: you can expand the algorithm application to a table of static mapping rules
(it provides an easy way to configure a standard NAT as a SD-CGN without
a line of C code :-).

---

From: Francis Dupont <[email-masked]>
Date: Wed, 14 Mar 2012 15:01:27 +0100

=> I leave the draft-penno-* unclear items to Reinaldo...

>  Med: I failed to get your first point. Could you please clarify? Thanks.

=> when what you can see from the Internet is a big port range per customer
it is trivial to track/trace customers. So what I call "none" algorithm
(i.e., no port translation by the SD-CGN) or "direct" algorithm
(i.e., port translation by adding a constant, the difference between
the first/base port of ranges) are bad according to (quoting
draft-tsou-softwire-port-set-algorithms-analysis):

   A good port set definition algorithm must be reversible, easy to
   implement, and should be able to define non-continuous or random port
   sets for better security, be able to exclude the well known ports, 0
   ~ 1023 or 0 ~ 4095, etc.

(BTW the last point doesn't apply to ICMP echo IDs)

The note is about no second NAT, i.e., "none" algorithm.

>  Med: applications using referral need to know the external IP address.

=> this comment is about the second NAT so as it doesn't translate
the IP address is out of context (but I agree there are more needs
for the external address than the external port)

>  Med: It is not "reasonable" when you don't have a DHCPv4 server but use PCP

=> PCP doesn't provide your IPv4 address. In fact, if you don't know your
assigned IPv4 address you can't run PCP, nor any applications over IPv4
(note DHCPv4 is not over IPv4 exactly for this reason).

> Med: We don't have the constraint of MAP so I would not exclude
> pseudo-random port set algos (see
> draft-tsou-softwire-port-set-algorithms-analysis-01#section-3.3)

=> I have no concern about them as soon as enough information
is given to SD-CPEs (including SD-B4s in the DS-Lite case) so
they can compute external ports as visible from the Internet.

Regards

PS: in fact for implementing a PCP/NAT-PMP/UPnP-IGD/etc
service on a SD-CPE you need the SD-CGN algo parameters
to implement:
 - something giving the next local (i.e., SD-CPE WAN side)
  external port. Note ++ is never enough as one must stay
  inside the allowed port range.
 - something (I call it map) giving the external port
  as visible from the Internet from the local external port
  value (i.e., applying the SD-CGN algo in the CPE to Internet
  way). Note this must not fail when the input is a valid
  (i.e., in range) value.
 - something (I call it unmap) giving the local external port
  from the value as visible from the Internet. Note this can
  be failed if the port doesn't belong to the customer
  translated port range (nothing really new: we already know
  a random external port is likely unavailable on a CGN).

---

From: <[email-masked]>
Date: Wed, 14 Mar 2012 15:15:59 +0100

Re-,

Please see inline.

Cheers,
Med 

> Envoyé : mercredi 14 mars 2012 15:01
> >  Med: It is not "reasonable" when you don't have a DHCPv4 
> server but use PCP
> >   for instance.
> 

Med: Why you need an IPv4 address to run PCP? An implementation example would be as follows:

* At bootstrap of the CPE, once an AFTR is discovered, use the Plain IPv6 PCP mode and the new opcode and options defined in http://tools.ietf.org/html/draft-tsou-pcp-natcoord-05#section-2 to retrieve an IPv4 address and set of port. 

* The IP address + port range returned in PCP will be used by CPE to enforce its NAT.

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 14 Mar 2012 14:32:53 +0000

I am a little lost. Let's put the double-nat aside for a moment. Except
the fact that sd-nat uses icmp for port-set provisioning, what else
different between Lightweight 4over6 vs. sd-nat? Am I missing something?
For Lightweight 4over6, we can use anycast for redundancy. I fail to see
what sd-nat does more than Lightweight 4over6.

/Yiu

On 3/14/12 8:47 AM, "[email-masked]"
<[email-masked]> wrote:

>Med: But the question is why ICMP-based method is needed? Why not using
>port-restricted DHCPv4 options for instance?
>

---

From: Francis Dupont <[email-masked]>
Date: Wed, 14 Mar 2012 16:13:03 +0100

In your previous mail you wrote:

>  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

=> this means the port range will be visible as it in the Internet,
IMHO this is not acceptable. And IMHO it is not the job of the SD-CPE
(i.e., it is the SD-CGN one) to translate the port range to something
far harder to track/trace.

>  In 'compatibility' mode, if the CPE fails to enforce the proper port
>  range, the AFTR will perform a second level of NAT.

=> if I understand well the compatibility mode is just the standard
DS-Lite where the B4 performs spurious and useless translation?
So in particular the only change for the AFTR is the customer IPv4
address?

>  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.

=> I believe it is more 'to be supported' than 'to interoperate with
stateless DS-Lite CPEs.

>     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

=> the IPv6-Transport DHCP Relay Agent (TRA, vs, the CRA, IPv6-Transport
Client Relay Agent)

>        requests simultaneously to acquire a number ports within the
>        same IPv4 address,

=> I can't see how this has a real chance to work...

>  IMHO, not specifying the technology to get port range and living this
>  to implementation is a serious shortcoming.  We need to standardize
>  one method.

=> I agree (on the one method, *not* on the proposed method).

Thanks

---

From: <[email-masked]>
Date: Wed, 14 Mar 2012 16:35:44 +0100

Please see below.

Cheers,
Med

> Envoyé : mercredi 14 mars 2012 16:13
> À : Alain Durand
> Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; Softwires WG; 
> draft-cui-softwire-b4-translated-ds-lite; 

Med: The PCP case has been demoed. Please refer to http://www.internetsociety.org/articles/new-technology-demo-pcp; in particular you can read:

   "In the second demonstration scenario, the CPE requested several sets
   of noncontiguous ports (utilizing draft-tsou-pcp-natcoord-03 and
   draft-zhou-softwire-b4-nat-02).  Upon receipt of the corresponding
   PCP request sent by the client, the PCP server requested the CGN to
   assign port forwarding and to bypass NAT on the requested port
   ranges.  The NAT function was performed on the CPE from this point
   forward, thus reducing the NAT processing requirement on the CGN
   router."

---

From: Qiong <[email-masked]>
Date: Thu, 15 Mar 2012 00:15:17 +0800

Dear all,

Please see inline .

On Wed, Mar 14, 2012 at 11:35 PM, <[email-masked]> wrote:

> Med: The PCP case has been demoed. Please refer to
> http://www.internetsociety.org/articles/new-technology-demo-pcp; in
> particular you can read:
>

[Qiong] We also have implemented and demoed in IETF 81th. Please refer to
http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-04.txt in
Appendix section.

Best wishes

Qiong

---

From: Qiong <[email-masked]>
Date: Thu, 15 Mar 2012 00:23:29 +0800

Me too.

And another comment:

In sd-nat, it says "More importantly, that draft (lightweight 4over6) does
not explain how this solution can be deployed in a regular DS-Lite
environment."

I think this is a deployment issue and lightweight 4over6 can definitely be
deployed in a regular DS-Lite environment. We have run a "Coexistent test
with DS-Lite" (refer to
http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-04.txt in
Appendix 1.3). It would be very easy and simple. Thoughts?

Best wishes

Qiong

---

From: Alain Durand <[email-masked]>
Date: Wed, 14 Mar 2012 23:24:04 -0700

> mechanism somehow changes.

One drawback of sdnat-01 was that the AFTR would still have to do ALG work, so it was not purely stateless.

So, instead of asking each CPE to use ports 1024 to 1024+max and then slide this range into the correct one in the AFTR,
sdnat-02  tells each CPE which actual port range min..max to use through the newly defined ICMP message.
The net result is that the AFTR does not need to perform any ALG work anymore, making it truly stateless

> the lightweight 4over6 draft, but I may miss something here.

The general idea is the same, however loghtweight 4over6 does not specify how to achieve it, it leaves the technique
to assign address and port open. stateless DS-lite (aka sdnat-02) does specify exactly how you achieve this.

> anycast for multiple AFTRs working?

See above, the AFTR is now entirely stateless. The port range is fixed, thus deterministic and no logs are necessary.

> find some protocol to synchronize the mapping automatically). Did I

Yes, this is correct. For a group of user sharing the same AFTR set, each AFTR in the set
is configured with the same anycast IPv6 address and the same IPv4 address pool and
per-subscriber mapping table. That IPv4 pool is announced as an anycast IPv4 route upstream by all AFTRs
in the set.

---

From: <[email-masked]>
Date: Thu, 15 Mar 2012 07:35:43 +0100

> De : [email-masked] 
> [mailto:[email-masked]] De la part de Alain Durand
> Envoyé : jeudi 15 mars 2012 07:24
> À : Peng Wu
> The general idea is the same, however loghtweight 4over6 does 
> not specify how to achieve it, it leaves the technique
> to assign address and port open. stateless DS-lite (aka 
> sdnat-02) does specify exactly how you achieve this.
> 

Med: I'm sorry to say this is not true. Please read: http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-05#section-5.
Four provisioning alternatives are listed there. If the WG want to make a decision on the ** mandatory ** one, this will be reflected in future version of the document.

---

From: Alain Durand <[email-masked]>
Date: Thu, 15 Mar 2012 04:10:30 -0700

On Mar 14, 2012, at 1:47 PM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

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.

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.

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

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 15 Mar 2012 13:18:40 +0000

>he is provisioned to use port restricted, then traffic still flows.
I failed to see how Stateless DS-Lite is different from B4 translated
DS-lite. We need to first understand what sd-NAT is trying to solve, then
decide whether it is needed or not.

>We need to standardize one method.

We can easily define a method in the B4 translated DS-lite draft. We have
few on the table (i.e. dhcpv4 over v6 transport, dhcpv6, radius, pcp). We
can ask the WG to decide which one should be in the base spec. This is how
RFC5959 was written. Alternatively, we can do what RFC6333 does. RFC6333
doesn't have any provision method defined except referring to RFC6334.

>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.

I need use cases. We don't have any issue using dhcp to manage ip address,
I fail to see why we need a different method to manage port-set. In the
end, A+P is extending the address with more bits from the port. Also, if
the ISP suddenly changes the port range, what happens to the existing
sessions? The CPE should close all the existing sessions or wait until the
sessions are done? Case 1, it will affect user experience; Case 2, sd-aftr
must keep track of the ports and don't assign them to another user until
the sessions are done. This sounds adding load to the aftr. If dynamic
port assignment is so important, why not use ds-lite instead?

>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

If the CPE was configured to get A+P but only asked for A, I consider this
is a configuration error. Even aftr used icmp to provision the port, the
CPE could still think it has the full address. I don't see how icmp could
solve configuration error.

>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

---

From: <[email-masked]>
Date: Thu, 15 Mar 2012 14:50:09 +0100

Re-,

Please see inline.

Cheers,
Med 

> Envoyé : jeudi 15 mars 2012 12:11

> he is provisioned to use port restricted, then traffic still flows.

Med: This is deployment-specific. The behaviour to follow when a port-restricted device issues port out of its allocated range should be IMO SP specific and can not be dictated by the specification. 

> 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.

Med: Changing the size of the port range is part of planned operations. With DHCP, an SP can change the port range much in advance. This is nothing something which can be done without advanced planning. I don't see an advantage of ICMP here.

>       This allows for more flexibility in micro-managing ports.

Med: This is also doable with DHCP and PCP by tweaking the Lease and the Lifetime.

> 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

Med: This doable with existing ICMP messages. Nothing prevent the AFTR to drop the packet and send back an ICMP Destination Unreachable message Code 3 "Port unreachable error" or Code 13 "Communication administratively prohibited".

> 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.

Med: No need to define a new ICMP message for this. Why not using e.g. ICMP Type 3 Code 13?

---

From: <[email-masked]>
Date: Thu, 15 Mar 2012 14:55:38 +0100

> De : Lee, Yiu [mailto:[email-masked]] 
> Envoyé : jeudi 15 mars 2012 14:19
> À : Alain Durand; BOUCADAIR Mohamed OLNC/NAD/TIP

> doesn't have any provision method defined except referring to RFC6334.

Med: I fully agree.

---

From: Alain Durand <[email-masked]>
Date: Thu, 15 Mar 2012 09:48:20 -0700

> only on port (vs. address and port) and following algorithm (aka stateless).

This 2nd NAT was the case in sdnat-01. This has changed in sdnat-02, where the SD-CPE
pre-shape IPv4 traffic with both address & port, so the SD-AFTR does only decapsulation
and ACL check. No NAT is done at all in the SD-AFTR.

   - Alain.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 15 Mar 2012 19:22:20 +0100

In your previous mail you wrote:

> * At bootstrap of the CPE, once an AFTR is discovered, use the Plain
>   IPv6 PCP mode and the new opcode and options defined in
>   http://tools.ietf.org/html/draft-tsou-pcp-natcoord-05#section-2
>   to retrieve an IPv4 address and set of port.

=> the retrieval of the external address is a function which was
explicitely put out of PCP by the WG, for the second you'd like to use
an extension which was never discussed. To finish there is a difference
between discussing about getting the IPv4 address or getting it with
other parameters as port ranges, and my comment is only about the first
problem.

Regards

PS: I should add another dimension: do we want a solution for DS-Lite or
a solution for DS-Lite, NAT44 or any other kind of IPv4 CGNs?

---

From: Francis Dupont <[email-masked]>
Date: Thu, 15 Mar 2012 19:32:35 +0100

In your previous mail you wrote:

>  Med: The PCP case has been demoed.

=> My comment is about PCP without any extension.

>     draft-zhou-softwire-b4-nat-02).

=> so this doesn't apply.

Regards

PS: we already have a configuration protocol, it is named DHCP.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 15 Mar 2012 19:42:04 +0100

>  http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-04.txt in

=> same: my comment is about the base PCP for port range discovery.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Fri, 16 Mar 2012 00:16:27 +0100

In your previous mail you wrote:

> 1) - we would have to define the DHCP port option. Not difficult but
> same amount of work as defining a new ICMP type.

=> is it a joke? DHCP has an extension mechanism, not ICMP.

> without having to wait for the lease time of the DHCP option to
> expire.

=> I don't understand the argument:
 - there is no lease time for an option
 - when the ISP change the port range it raises an ICMP error for
  the first packet which falls outside the new range
 - when the CPE receives the ICMP error it refreshes the port range
   info
So the mechanism doesn't rely in the info being carried in the ICMP.
Note this doesn't solves 2 cases where the ICMP can't help:
 - when the port range is in fact the ICMP echo ID range
 - when the port range is extended

>  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.

=> there are many ways to solve this, for instance the server can
refuse to give an IP address or recognize the CPE as being not
SD-CPE capable, etc.

>  something is wrong if/when it sends packets outside of the range.

=> ICMPv4 administratively prohibited (no need for a new message).

>  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).

=> port 0 is invalid so will be likely drop sooner than expected.
I don't even believe the ICMP stuff of draft-penno-softwire-sdnat
could work in a lab, so in the real world...

Regards

---

From: Francis Dupont <[email-masked]>
Date: Fri, 16 Mar 2012 00:37:57 +0100

>  decide whether it is needed or not.

=> I agree and IMHO they have the same issue: the per-CPE port range
is far too easy to track from the Internet side. IMHO the port
restricted CPE is a good idea (it should be deployable in most
existing CPEs without changing a bit to kernels) but CGN should
provide an algorithmic (including the identity) port translation to
shuffle CPE port ranges.

>  doesn't have any provision method defined except referring to RFC6334.

=> I agree on the principle but we should answer to a question first:
do we want a mechanism for DS-Lite only or a mechanism applicable
to DS-Lite, NAT44 and any other IPv4 CGN?

>  I fail to see why we need a different method to manage port-set.

=> me too.

>  Also, if the ISP suddenly changes the port range, what happens to
>  the existing sessions? The CPE should close all the existing
>  sessions or wait until the sessions are done?

=> I had the same question and there are two solutions: a smooth
hard to implement and a rude easy to implement, beginning with
the second:
 - flush the whole context (your first case)
 - kill only connections which are no longer valid (there is nothing
  to do for them and you can be lucky...)
To wait is not an option because they are already blocked by the CGN.

>  Case 2, sd-aftr must keep track of the ports and don't assign them
>  to another user until the sessions are done. This sounds adding
>  load to the aftr.

=> this is incompatible with port ranges and the fact the lifetime
of a session is potentially unbound. So there is nothing smooth/
user-friendly you can do on the SD-CGN other than never restrict
assigned port ranges.

>  port assignment is so important, why not use ds-lite instead?

=> perhaps to try to make port reassignment of a lower order of
annoyance than address reassignment?

Regards

---

From: Francis Dupont <[email-masked]>
Date: Fri, 16 Mar 2012 00:42:42 +0100

+1

>  Please see inline.

(I cut here: too long and unreable with not-ASCII characters,
quoted-printable silly coding and long lines)

Regards

---

From: <[email-masked]>
Date: Fri, 16 Mar 2012 07:29:38 +0100

Hi Francis,

Yes, you are right. There is no explicit method in PCP to get the external IP address. You know we have both asked for it in early days of PCP but the WG consensus was that we can mimic this by using MAP with short lifetime.

As for your PS, this a discussion point for the PCP WG. 

Cheers,
Med 

>Envoyé : jeudi 15 mars 2012 19:22

---

From: "Qi Sun" <[email-masked]>
Date: Sun, 18 Mar 2012 00:36:52 +0800

Hi Med,

      I read through the draft-penno-* and IMHO it is reasonable in the view of deployment.  By configuring the profile (i.e. the per-subscriber mapping table) in the AFTRs, the SPs can achieve an explicit binding between the IPv4 address + port-set and the customer. This can mean the customer pay for the ownership of the IPv4 address + port-set. It is easy to associate address(port-set) assignment with authentication.

Best Regards

Qi Sun

---

From: Qi Sun <[email-masked]>
Date: Sun, 18 Mar 2012 00:44:28 +0800

Hi Med,

      I've
read through the draft-penno-* and IMHO it is reasonable in the view
of deployment.  By configuring the profile (i.e. the per-subscriber
mapping table) in the AFTRs, the SPs can achieve an explicit binding
between the IPv4 address + port-set and the customer. This can mean
the customer pay for the ownership of the IPv4 address + port-set. It
is easy to associate address(port-set) assignment with authentication.

Best Regards!

Qi Sun

---

From: "Qi Sun" <[email-masked]>
Date: Sun, 18 Mar 2012 11:51:16 +0800

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; [email-masked]
Subject: Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite

=> my answer is simple:

[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?

[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.

Regards

---

From: Alain Durand <[email-masked]>
Date: Tue, 20 Mar 2012 06:06:26 -0700

On Mar 17, 2012, at 12:44 PM, Qi Sun wrote:

> Hi Med,
> 
>       I've read through the draft-penno-* and IMHO it is reasonable in the view of deployment.  By configuring the profile (i.e. the per-subscriber mapping table) in the AFTRs, the SPs can achieve an explicit binding between the IPv4 address + port-set and the customer. This can mean the customer pay for the ownership of the IPv4 address + port-set. It is easy to associate address(port-set) assignment with authentication.
> 
> Best Regards!
> 
> Qi Sun

Thank you for your comment. Indeed, it is both simple and necessary to know on the AFTR which ports belong to which subscriber.

It is simple because this can be configured out-of-band (think netconf) from a centralized repository. Note, that, using
a centralized repository for subscriber <-->  IPv4 address & port mapping, the service provider has the flexibility to
allocate different numbers of ports according to the subscriber profile. More, because the association subscriber
<--> IPv4 address and port is known, there is no need for logging of any sort on the AFTR.

It is necessary because the AFTR is the only place where we can enforce IPv4 ingress filtering, ie put ACLs to check
that the incoming tunneled traffic from any given customer is using a legitimate IPv4 address and source port.
When the incoming traffic does not match those ingress filtering rules, an ICMP error message must be returned.
The idea in SD-NAT is to use this ICMP message to carry the information about the correct port range to use.

Alain.

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 20 Mar 2012 15:39:29 +0000

Today, if a user generates a packet using an illegal IPv4 source address,
what would we do? We could drop the packet silently by doing
source-verify. So, tomorrow if a user use illegal port, IMHO AFTR should
drop the packet silently.

On 3/20/12 9:06 AM, "Alain Durand" <[email-masked]> wrote:

>It is necessary because the AFTR is the only place where we can enforce
>IPv4 ingress filtering, ie put ACLs to check

---

From: <[email-masked]>
Date: Tue, 20 Mar 2012 17:05:41 +0100

Hi Yiu,

Sending back an ICMP message when receiving a port out of range should be configurable IMHO. 

When receiving a port out of range, the behaviour of REQ#12 (A, B and C) of http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-05#section-3 can be followed by the AFTR.

No need to define a new ICMP message for this; ICMP message Type 3 Code 13 is fine for this.

Cheers,
Med 

>[mailto:[email-masked]] De la part de Lee, Yiu
>Envoyé : mardi 20 mars 2012 16:39
>À : Alain Durand; Qi Sun
>>When the incoming traffic does not match those ingress 
>filtering rules,
>>an ICMP error message must be returned.
>>The idea in SD-NAT is to use this ICMP message to carry the 
>information
>>about the correct port range to use.
>

---

From: Peng Wu <[email-masked]>
Date: Wed, 21 Mar 2012 12:05:43 +0800

Hi Alain,

I get what you are saying, but I still have one question: so this
repository, is it dynamic is some way?
For example, what happens if some user whose IPv6 address is not
profiled requires enters, or some user is profiled leaves?
Or we are supposing that the ISP knows all the user IPv6 prefixes and
configures all the address mappings in some initial phase, so no
matter what happens in the user side, the address mapping always
remains?

This can help us to understand the SD-NAT draft more precisely.

Thx~

---

From: Francis Dupont <[email-masked]>
Date: Mon, 26 Mar 2012 18:57:29 +0200

>  drop the packet silently.

=> it is a bit different in this case because it is not an illegal
port but a misconfigured port. I agree to drop junk packets but for
misconfed it is better to send an ICMP 3/13 (unreachable / admin
prohibited) by default with a knob to silently drop (in the case you
believe there should not be misconfed, for instance because you froze
the config 6 month ago).

Regards

---

From: Francis Dupont <[email-masked]>
Date: Mon, 26 Mar 2012 19:00:25 +0200

In your previous mail you wrote:

>  When receiving a port out of range, the behaviour of REQ#12 (A, B
>   and C) of
>   http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-05#section-3
>   can be followed by the AFTR.
>

+1 (and not only I agree but I implemented this in the ISC AFTR)

Regards