Re: Comments on the NAT66 draft

[Rémi Després <[e-mail]>]

Wes Beebee (wbeebee)   (1-12/1-31/200x) 11/6/08 2:59 PM:

As we move to IPv6, NAT44, NAT64, and NAT46 will eventually go away.  The problem with helping NAT66 (even when that is not your intent) is that once it catches on, it'll be in the Internet forever and will never go away.

"NATs necessary for IPv6, says IETF chair"
http://www.networkworld.com/news/2008/072109-nat-housley-qna.html" rel="nofollow">http://www.networkworld.com/news/2008/072109-nat-housley-qna.html
  

There will indeed be NAT64s, and possibly NAT46s: they are necessary to satisfy some specific requirements. This justifies the chair's message.

But this does not imply that NAT66s are ALSO necessary: provided appropriate mapping based solutions are deployed for v6-v6, there are only negative effects to be expected from real NAT66s.

Once NAT66 gets out, I can imagine even more damaging headlines (which conveniently miss all the subtleties of the message in section 3 of http://www.ietf.org/internet-drafts/draft-mrw-behave-nat66-00.txt" rel="nofollow">http://www.ietf.org/internet-drafts/draft-mrw-behave-nat66-00.txt): "IETF Standardizes IPv6-to-IPv6 NAT".
  

This is precisely what can be avoided by using a more appropriate terminology: in Margaret's document, "mapping" appears 46 times;  "translation"  appears 4 times (3 times to define NAT66, and 1 time where mapping could have  been used as well).

Regards,
RD

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Thursday, November 06, 2008 5:59 AM
To: Wes Beebee (wbeebee)
Cc: Rémi Després; Margaret Wasserman; Behave WG; [e-mail]
Subject: Re: Comments on the NAT66 draft

Personally I am scared of anything that seems to make NAT suggestions for v6. 

That said, I think that section 3 could use a little more meat to explain some of the problems with NAT in terms of breaking connections etc rather than just pointing towards RFC 4864 as I am not sure that people will go and look at the cross reference. 

I would encourage discussion on this to see if there is a consensus for proceeding with giving hints or help to a concept that "IETF does not recommend" 

Eric 


Wes Beebee (wbeebee) writes: 

  

I understand that NAT66 work on the details is being done in the BEHAVE Working Group - but shouldn't we also include a discussion at v6ops on whether NAT66 should be standardized?  After all, they're more privy to the discussions that created the Local Network Protection RFC...
 
- Wes

________________________________

From: [e-mail] [mailto:[e-mail]] On 
Behalf Of Rémi Després
Sent: Wednesday, November 05, 2008 10:21 AM
To: Margaret Wasserman
Cc: Behave WG
Subject: [BEHAVE] Comments on the NAT66 draft


Hi Margaret,

Sorry for so late an answer (I was too busy preparing my own draft before the deadline). 
Here are my comments, section per section.  

Sec. 3 - Motivation)
a. I _FULLY SUPPORT_ that IETF should standardize some ways to keep, in IPv6, appreciated benefits of NAT44s (and to avoid as much as possible their drawbacks). 
b. In your list of NAT44 appreciated services (i.e. provider independent addressing, simplified site multihoming, topology hiding), "host privacy" should IMHO be added. This is the impossibility, from the outside, to see that several consecutive connections were initiated by the same host. 
c. Concerning multihoming, a more detailed analysis of what NATs do, 
and don't do, would be a useful clarification. (In particular, they  
are incompatible with multihoming of both Shim6 and SCTP. These the 
protocols, to take advantage of multihoming, exchange address 
information in payloads, protected by strong checksums.)

Sec. 4 - NAT66 overview
a. Since your proposed mechanism is only based on stateless and reversible  _mappings_, calling it a NAT leads, IMHO, to confusion: NATs are generally understood, and used, as NAPTs. They do  stateful and  non-reversible 1:n  _translations_. 
b. With a different name than NAT for such a proposal, IETF could advertise that it _does not endorse NATs in IPv6_. This would IMHO increase  (or restore?) confidence in IPv6. "Mapping" instead of "translation"would be a logical word in such a name. 

Sec. 5 - NAT66 Address Mapping Mechanisms
- Topology hiding is in fact possible without losing reversibility of the mapping. Cf the comment on 5.1.2.  

Sec. 5.1 - Checksum-Neutral Mapping
- IMHO, it would be useful to make it clear in this section (like in the introduction) that the proposed mapping does not apply to addresses that are transmitted in payloads.  ALGs could be be added to convert addresses in TCP payloads TCP, as it is done in some NAT44s.  But it cannot be done not in SCTP payloads because of the stronger checksum algorithm.  

Sec. 5.1.1 - Two-way Algorithmic Address Mapping
- The proposed limitation to /48 internal and external prefixes is stronger than necessary. 
- A sufficient limitation is that external prefixes are not longer than internal ones. (If  the external prefix is shorter, a few 0 bits can be added to it, up to the  length to the internal one.) For example a /56 external with a /60 internal should be permitted.  

Sec. 5.1.2 - Topology hiding Option
- For outgoing UDP and TCP connections, it is in fact possible to hide the internal topology without losing  reversibility of the mapping:  the algorithmic mapping is, for this, applied jointly to the subnet identifier AND to port bits (excluding port-bits 0 and 1 that must remain constant in dynamic ports). UDP and TCP checksums are then incrementally adjusted (like IP checksums). 
- In addition to topology hiding, this mechanism provides _host privacy_ , as defined in the comment on sec. 3 :-) .  

Sec 6. - Prefixes for Port Mapping
- I don't see the need for this section in this document. The mapping applies to internal and external  prefixes, independently of how they can be configured.  

Sec 7 - A note on Port Mapping
- Agreed: address amplification should not be needed in IPv6. Agreed 
also: some transport layers that encrypt data are incompatible with 
port mapping. But this is not sufficient to abandon port mapping 
all-over. (See the comment on 5.1.2.)

Sec 8 - Security Considerations
- In TCP, DCCP, SCTP, packets that initiate connection establishments  can be individually recognized (SYN without ack in the case of TCP). Incoming connections  can therefore be blocked with stateless operation, but this is not the case for UDP (per-connection stateful operation is needed). Whether blocking UDP incoming connections is worth it, in global to local IPv6 gateways, is  therefore uncertain (hosts must anyway have their own blocking of undesirable incoming connections).  

In summary: 
- the document  introduces IMO a *very useful subject*. 
- Before freezing any recommendation,  its relationship with other layers, in particular with other stateless address mappings, should be further studied.  

Best regards,

RD


Margaret Wasserman   (1-12/1-31/200x) 10/27/08 7:59 PM:  


	I have posted a NAT66 draft, so that we can have a better-grounded discussion of whether it makes sense to include NAT66 as a work item in the behave charter.  The draft can be found at the following URL: 
	
	http://www.ietf.org/internet-drafts/draft-mrw-behave-nat66-00.txt" rel="nofollow">http://www.ietf.org/internet-drafts/draft-mrw-behave-nat66-00.txt
	
	Feedback would be greatly appreciated!