Subject: [nat66] Fwd: New Version Notification for draft-mrw-nat66-00

From: Margaret Wasserman <[email-masked]>
Date: Mon, 18 Oct 2010 15:05:21 -0400

Hi All,

I just submitted a new version of the NAT66 draft (see below).  This  
one includes a NAT66 algorithm for prefixes longer than /48.

I also changed the name of the document to remove the pointer to the  
behave WG, and I updated my contact information.

Comments?

Margaret

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: October 18, 2010 2:49:17 PM EDT
> To: [email-masked]
> Cc: [email-masked]
> Subject: New Version Notification for draft-mrw-nat66-00
>
>
> A new version of I-D, draft-mrw-nat66-00.txt has been successfully  
> submitted by Margaret Wasserman and posted to the IETF repository.
>
> Filename:	 draft-mrw-nat66
> Revision:	 00
> Title:		 IPv6-to-IPv6 Network Address Translation (NAT66)
> Creation_date:	 2010-10-18
> WG ID:		 Independent Submission
> Number_of_pages: 15
>
> Abstract:
> This document describes a stateless, transport-agnostic IPv6-to-IPv6
> Network Address Translation (NAT66) function that provides the
> address independence benefit associated with IPv4-to-IPv4 NAT (NAT44)
> while minimizing, but not completely eliminating, the problems
> associated with NAT44.
>
>
>
> The IETF Secretariat.
>
>

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 18 Oct 2010 15:43:53 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Margaret Wasserman
> Sent: Monday, October 18, 2010 12:05 PM
> To: NAT66 HappyFunBall
> Subject: [nat66] Fwd: New Version Notification for draft-mrw-nat66-00
> 
> 
> Hi All,
> 

If you haven't already, please drop an email to [email-masked]
asking for a tombstone for draft-mrw-behave-nat66 pointing to your
new draft.  I know a lot of existing references to the old draft and
it would be good if they followed to the new draft.

side-by-side diff,
http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-mrw-behave
-nat66-02.txt&url2=http://tools.ietf.org/id/draft-mrw-nat66-00.txt
or http://tinyurl.com/2fg6rj4

Nit: very bottom of Section 8 says "described below"; better would be a
forward
reference to the specific section number.

The new section 9 says:

   Although any 16-bit portion of an IPv6 IID could contain 0xFFFF, an
   IID of all-ones is a reserved anycast identifier that should not be
   used on the network [RFC2526].  

So, that's saying "a non-0xFFFF pattern will exist somewhere."

   If a NAT66 device discovers a packet
   with an IID of all-zeros while performing address mapping, that
...........^^^^^^^^^^^^^^^^
Is "all-zeros" intended here, or "all-ones"?  Is all zeros a problem?

   packet MUST be dropped, and an ICMPv6 Parameter Problem error SHOULD
   be generated [RFC2463].

Nit: it might be helpful if section 8 and 9 were subsections below a general
'algorithm' section, something like:

  8.  IP Address Mapping Algorithms
  8.1.  Prefixes shorter than /48
  8.2.  Prefixes longer than /48

At end of first paragraph of Section 12 ("A Note on Port Mapping") it might
be useful to add a reference to RFC3022 which defines Network Address and
Port 
Translator (NAPT).  

-d

> _______________________________________________
> nat66 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nat66

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 18 Oct 2010 19:45:28 -0400

Thanks, Dan!!

I'll see if I can get another update done to fix your changes before  
the final draft cut-off.

Margaret

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 18 Oct 2010 16:49:30 -0700

Thanks.  

I neglected to say:  the important addition looks like it'll work fine and
is described well.

-d

> From: Margaret Wasserman [mailto:[email-masked]]
> Sent: Monday, October 18, 2010 4:45 PM
> To: Dan Wing
> Cc: 'NAT66 HappyFunBall'
> Subject: Re: [nat66] Fwd: New Version Notification for draft-mrw-nat66-
> 00
> 
> 
> 
> Thanks, Dan!!
>

---

From: Rémi Després <[email-masked]>
Date: Tue, 19 Oct 2010 14:49:09 +0200

Hi , Margaret,

The introduction rightly says "This document describes a stateless, transport-agnostic IPv6-to-IPv6 Network Address Translation".

The word "stateless" being key in the design, having it also in the title would IMHO be a useful clarification.
It could become "Stateless IPv6-to-IPv6 Network Address Translation (NAT66)".

Regards,
RD

Le 19 oct. 2010 à 01:45, Margaret Wasserman a écrit :

> 
> 
> Thanks, Dan!!
> 
> I'll see if I can get another update done to fix your changes before the final draft cut-off.
> 
> Margaret
>

---

From: <[email-masked]>
Date: Tue, 19 Oct 2010 15:31:22 +0200

Margaret,

Section 11 of your draft states that the ULA prefix should be selected randomly.

Have you considered selection of ULA prefix(es) for internal network in such a manner that it/they can be translated to NAT uplink's /64 prefix in checksum neutral fashion?

Additionally, if stateful address autoconfiguration (DHCPv6) is used in the network deploying NAT66, have you considered that the DHCPv6 server could choose /128 addresses in a fashion allowing checksum neutral translation by NAT66?

Best regards,

Teemu

> Of ext Margaret Wasserman
> Sent: 18. lokakuuta 2010 22:05
> To: NAT66 HappyFunBall

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 19 Oct 2010 10:02:52 -0400

Hi Teemu,

On Oct 19, 2010, at 9:31 AM, <[email-masked]> <[email-masked] 
 > wrote:

> Have you considered selection of ULA prefix(es) for internal network  
> in such a manner that it/they can be translated to NAT uplink's /64  
> prefix in checksum neutral fashion?
>
> Additionally, if stateful address autoconfiguration (DHCPv6) is used  
> in the network deploying NAT66, have you considered that the DHCPv6  
> server could choose /128 addresses in a fashion allowing checksum  
> neutral translation by NAT66?

This is an interesting idea, however it undermines the purpose of  
NAT66...  If the internal addresses are chosen to allow checksum  
neutral translation to external addresses, then the internal addresses  
will need to be changed whenever the site is renumbered by an ISP, or  
when a site changes ISPs.

If the internal addresses are dependent on the external addresses, I  
don't see the advantage of using NAT66.  You could, instead, just  
number the internal links with global addresses.

Margaret

---

From: <[email-masked]>
Date: Tue, 19 Oct 2010 16:27:22 +0200

> number the internal links with global addresses.

True, but I think the significance depends on the deployment case at hand (it might happen that NAT66 "leaks" to scenarios outside of the intended purpose).

If the internal network is small and fully automatically numbered using SLAAC, the nodes are anyhow prepared for prefix lifetime expiration and should easily switch to use new prefix having longer lifetime for all new connections.

Hence if the uplink prefix changes (or new one becomes available) the NAT66 device might have to do some checksum recalculation for packets until the internal network is automatically renumbered with new ULA providing the checksum neutral property. As the new ULA is probably advertised quickly, all new sessions should start to use it and hence performance impact for NAT66 (caused by checksum calculation effort) does not last too long?

Anyhow, just a thought to include or not in addition to random ULA. 

Best regards,

Teemu

P.S. I would prefer world without NATs.. I actually recall hearing not long ago that astronomers found one pretty promising in a nearby solar system?-)

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 19 Oct 2010 11:00:27 -0400

Hi Remi,

On Oct 19, 2010, at 8:49 AM, Rémi Després wrote:
> The word "stateless" being key in the design, having it also in the  
> title would IMHO be a useful clarification.

I've received several suggestions to rename the document, but there  
has been no consistency in what people think it should be named.

I'm personally happy with the current name, and I don't see a  
compelling reason to change it.

Margaret

---

From: Rémi Després <[email-masked]>
Date: Tue, 19 Oct 2010 17:49:37 +0200

Le 19 oct. 2010 à 17:00, Margaret Wasserman a écrit :
> I've received several suggestions to rename the document, but there has been no consistency in what people think it should be named.

I was not aware of such suggestions, at least on the list.
Sorry if I missed them.

> I'm personally happy with the current name, and I don't see a compelling reason to change it.

That's clearly up to you to decide, but which reason you have (compelling or not) to object to the clarification remains unclear.

Le me explain more:
- The problem starts when one talks about a "stateful NAT66",.
- If your draft can be understood as implying that all NAT66's are stateless, stateful NAT66 becomes a self contradictory expression.
- Yet, if one wants to translate addresses, a stateful NAT66 makes a lot of sense too . This has become clear since draft-ietf-v6ops-cpe-simple-security requires for security reasons, that even unmanaged CPEs have a stateful processing at the transport layer. 

Regards,
RD

---

From: "S.P.Zeidler" <[email-masked]>
Date: Thu, 21 Oct 2010 07:34:56 +0200

Hi,

> Have you considered selection of ULA prefix(es) for internal network in such a manner that it/they can be translated to NAT uplink's /64 prefix in checksum neutral fashion?

That will likely not work if you have several prefixes that you want to
translate into.

This is the scenario where prefix translation does not get used to prevent
renumbering but to make multi-homing with several distinct /48 PA to
different uplink providers halfway sane, by delegating the routing
decisions back to the router (NAT66 device) instead of requiring every
host on the LAN to be able to make useful routing decisions and pick
the right source prefix.

regards,
	spz
-- 
[email-masked] (S.P.Zeidler)

---

From: jouni korhonen <[email-masked]>
Date: Thu, 21 Oct 2010 10:06:42 +0300

Hi,

> That will likely not work if you have several prefixes that you want to

Teemu is referring here to a specific deployment scenario, which is using a cellular phone as a mobile router. In this case, there is only one uplink and the uplink always has a single /64. I admit the deployment scenario is rather specific/limited but not necessarily a corner case (expecting that the penetration of cellular phones with e.g. WLAN is going to be wide spread).

> host on the LAN to be able to make useful routing decisions and pick

- Jouni

---

From: "S.P.Zeidler" <[email-masked]>
Date: Thu, 21 Oct 2010 09:41:34 +0200

Hi,

> >> Section 11 of your draft states that the ULA prefix should be selected randomly.

RFC4193 states: 'Locally assigned Global IDs MUST be generated with a
pseudo-random algorithm consistent with [RANDOM].' too.

> Teemu is referring here to a specific deployment scenario, which is using a cellular phone as a mobile router. In this case, there is only one uplink and the uplink always has a single /64. I admit…

In this case, do you expect the network connected to the phone to be
structured? Even if the ULA is determined randomly, it is still a /48 and
the /64 picked to be used on the inside need not be random at all.

Remains the question why you'd bother with NAT66? What advantage does it
deliver over using the public addresses directly?

regards,
	spz