Subject: Re: [BEHAVE] draft-jennings-behave-nat6-00.txt

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 4 Aug 2008 14:42:27 +0200

On 7 jul 2008, at 6:06, Cullen Jennings wrote:

> A draft related to the nat64 and nat46 topic ....

    A record query, and then it composes a v6 address formed by  
putting a
    ::FFFF/96 prefix before the v4 address.

What you wrote here is the prefix formed by the 96 most significant  
bits of the address 0:0:0:0:0:0:0:ffff = 0:0:0:0:0:0. I don't think  
that's what you had in mind.

Also note that using the v4-mapped prefix (::ffff:0:0/96) would  
require changes to all major OSes, as they will only generate IPv4  
packets towards this destination prefix and not IPv6 packets. (See  
what I wrote on the int area list.)

You put the burden of being reachable for IPv4 clients on the IPv6  
server. This makes sense in the current situation where being  
connected to the internet means having IPv4 connectivity. However, it  
doesn't solve the case where IPv4 clients want to connect to IPv6  
servers that _don't_ have an IPv4 address similar how NAT64 allows  
IPv6 clients to connect to IPv4 servers that don't have an IPv6 address.

    Typically a STUN server would be used.  Note that a
    UDP transaction to a STUN server will allocate a mapping that can be
    used for incoming TCP connections.  The NAT is required to run a  
STUN
    server on the external side at the address ::FFFF:127.0.0.1 on the
    default STUN port so the server will always be able to find a STUN
    server if it is behind a NAT.

Yes, something like this makes sense.

    The servers that tend to be popular to run behind NATs are mostly  
P2P
    applications, such as file sharing and VoIP.

I would prefer to stay away from the word "server" for this case, and  
reserve that for the simple client/server model servers.

    Note that any IP options are lost in this process; also, as
    defined in UDP and TCP, new checksums will be computed.

The fragment header needs to be handled.

I would say that the checksums are updated. I.e., if a packet comes in  
with an incorrect checksum, it's not the NAT's job to detect that, let  
alone correct it. The checksum should just be incrementally updated to  
reflect the modifications to the packet.

I think the discussion of MTU/fragmentation related issues is useful,  
apparently we never put this in the NAT64 document...

However:

    The NAT MUST support reassembly of fragmented packets when the
    packets are received in order, but support for out of order  
fragments
    is OPTIONAL.

@ NAT64 co-authors:  :-)

    If the NAT receives a v4 packet with the do not fragment bit set, it
    MUST NOT forward it if the MTU of the v6 link would require the
    packet to be fragmented, and the NAT MUST NOT include a fragment
    header in the v6 packet.

Why MUST? SHOULD is more than strong enough.

    If the NAT receives a v4 packet that does
    not have the do not fragment bit set, then the packet, when
    forwarded, MUST include a fragment header

Huh? Do you mean that you translate the fragments rather than  
reassemble and refragment?

    When the NAT receives a v6 packet without a fragment header, it MUST
    set the do not fragment bit in any v4 packets

I guess this is to allow for path MTU discovery. However, as discussed  
in the meeting last week, IPv6 hosts don't believe in maximum packet  
sizes smaller than 1280 bytes so this won't work if the IPv4 MTU is  
smaller than 1260 bytes. Solution:

- set the DF bit to 0 for IPv6 packets <= 1280 bytes
- set the DF bit to 1 for IPv6 packets > 1280 bytes

(May want to mention at some point that sending ICMP "too big"  
messages is a MUST.)

    NAT processing of ICMP errors is complicated and of very limited
    value; for that reason forwarding ICMP error messages is OPTIONAL.
    Processing to allow ping and traceroute through the NAT is also
    OPTIONAL

Disagree. You MUST be able to translate ICMP to support path MTU  
discovery anyway, so anything that only requires straight ICMP  
translation can be easily supported. This includes various  
unreachables, which are important to avoid application timeouts in  
certain cases. Pings and probably even traceroutes should work without  
issues with this type of translation.

Telling vendors that it's ok to ignore ICMP is not a message the IETF  
should be sending, especially because users won't be able to vote with  
their feet by selecting a different vendor for these types of  
translators as they're deployed by service providers.

    UDP is the new thin waist of the internet.  IPsec over UDP will  
work,
    but other forms of IPsec will generally not work in a reliable way.

Host changes are necessary on at least one end because of the non- 
matching IP versions that the translator can't change because of  
authentication and/or encryption.

5.8.  DCCP, SCTP, etc

    The strong temptation is to extend this specification to support
    these protocols.  However, that path is probably doomed and would
    just add needless complexity.  The issue is, if there were ever any
    applications to use these protocols, the applications would probably
    want to work through the existing deployed v4 to v4 NATs, which do
    not support these transports.  As a result the new transports are  
not
    useful to applications unless they are adapted to work over existing
    NATs - most commonly by running them over UDP.

I agree that when building a hack like NAT64 to get existing stuff to  
work, it's not an obvious choice to future-proof the hack.

Note that SCTP won't work by just encapsulating it in UDP because of  
its address management.

    This approach does not require any DNS ALG.  The downside is that  
the
    servers in the 4 to 6 case need to discover and advertise their v4
    addresses, rather than letting the NAT and DNS automatically
    coordinate them.  One of the upsides of this design is that DNSSEC
    can work

No DNS ALG = broad definition, this includes the DNS64 functionality  
from our NAT64 draft (although that's not an ALG). With the v4-mapped  
prefix hosts will automatically create the necessary IPv6 addresses  
from A records but as stated before, those addresses won't generate  
IPv6 packets. So host changes are required one way or another if  
synthetic AAAA records are out.

    FTP.  There is no need for an FTP ALG; use EPSV.

I don't have any numbers, but I'm pretty sure there are still  
significant numbers of FTP servers that only support PASV out there.  
However, requiring those to be updated is preferable to implementing  
ALGs, IMO. So agree.

    DHCP is very useful for the automated configuration of many things
    beyond IP addresses. [[ TODO should any particular DHCP things be
    required]]

Disagree on principle (RAs are the One True Way), and disagree that  
it's useful to mention DHCP in the helper services part of this  
document. Not even wasting key clicks on 7.4

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 4 Aug 2008 14:46:29 +0200

On 17 jul 2008, at 1:05, Brian E Carpenter wrote:

> Conceptually, I definitely prefer the draft-bagnulo-behave-nat64
> model (which I think of as a SIIT protocol translator in series
> with a pretty much industry-standard IPv4-IPv4 NAT).

This is not really true: a NAT64 translator (as well as a dual stack  
"lite" carrier grade NAT) demultiplex on the IPv6 address, not on a  
private IPv4 address. This is a small but important difference that  
makes these translators much cleaner and more capable than regular  
NAT44 translators.

> I think the draft-jennings-behave-nat6 approach has the negative
> characteristic of importing NAT-related issues into IPv6-related
> code, and that is something we want to avoid if we can.

Agree.

However, now that the IPv6-firewall-enabled-by-default cat is out of  
the bag, techniques like ICE are probably needed to make IPv6-IPv6  
peer-to-peer sessions more robust. ICE _should_ be able to work across  
the IPv4/IPv6 boundary, so it doesn't seem to onerous to expect ICE  
support for IPv6 peer-to-peer applications.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave