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: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] 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
Feedback would be greatly appreciated!