Subject: [BEHAVE] Comments on draft-baker-behave-v4v6-translation-02

From: Dave Thaler <[email-masked]>
Date: Fri, 17 Apr 2009 16:20:41 -0700

Attached is a marked up copy with my comments inline.

A summary of some of the main ones:

* As discussed in the WG meeting, I believe this document
  should be independent of the mechanism used to choose
  the source/dest addresses to put into a translated
  header.  This doc shouldn't require updating if another
  mechanism is added in the future, and it should be
  sufficient to apply to SIIT, BIS, NAT64, SAM, IVI, etc.

* RFC 2765 assumes a (1's complement) checksum-neutral
  address translation.  The current draft assumes a
  non-checksum-neutral address translation.  Personally,
  I strongly prefer checksum-neutral translation (and
  I believe this can be done, as shown by Margaret for
  NAT66 and I believe the same concept can work for
  IPv4<->IPv6 translation).  Hence I would want the
  SIIT update to either assume checksum-neutral translation
  if we know of no reason to allow non-neutral, or else
  allow for either possibility (which would provide
  better assurance that we won't need to update the
  document in the future).

-Dave

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 20 Apr 2009 15:01:17 +0200

>  better assurance that we won't need to update the

I agree, also strongly. In the case of a 1-to-1 translation, there is  
no obvious reason why the translation can't be checksum-neutral and  
hence work with non-TCP/UDP transport protocols, including future  
ones, without problems. It should also save some cycles in the  
translation process.

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Apr 2009 10:04:53 -0400

Iljitsch van Beijnum wrote:
> I agree, also strongly. In the case of a 1-to-1 translation, there is no
> obvious reason why the translation can't be checksum-neutral and hence
> work with non-TCP/UDP transport protocols, including future ones,
> without problems. It should also save some cycles in the translation
> process.

I don't have any problem with a checksum-neutral address mapping
algorithm, but let's not kid ourselves.  There's no guarantee that such
a translation will "work with non-TCP/UDP transport protocols, including
future ones, without problems" because there's no guarantee that future
transport protocols will use the same checksum algorithm.

(I also don't see how it saves cycles in the translation process, as the
effort required to calculate the mapped address is about the same as
that required to incrementally update the checksum.)

I also don't think that the idea can be applied to IPv4<>IPv6 mapping in
general, because there are several other design considerations for such
mapping.  Another way to put this is that I don't see any broad
applicability for stateless v4<>v6 mapping - I think it's a corner case
that will not be used terribly often in practice.

Keith

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 20 Apr 2009 16:36:12 +0200

On 20 apr 2009, at 16:04, Keith Moore wrote:

>> In the case of a 1-to-1 translation, there is no

> a translation will "work with non-TCP/UDP transport protocols

Since when are there any guarantees anywhere in life?

> including

True. But DCCP does. And SCTP, that doesn't, doesn't include the  
pseudo-header in the checksum, which is, in my opion, the correct way  
to do things without violating layers. On the other hand, SCTP  
includes address management that would probably fail in the presence  
of protocol translation.

In a one-to-many NAT when there is a protocol that doesn't have port  
numbers (as far as the NAT knows) the NAT can only create a one-to-one  
mapping so only one user can use the protocol. In the case of a one-to- 
one translator that's not exactly a limitation so the only issue would  
be a protocol that uses the normal checksum including pseudo-header.  
Protocols that don't use a checksum (such as tunnels) or don't include  
the pseudo-header should work without trouble if the translator  
translates just the IP header. So I guess this issue isn't all that  
prominent. Then again, the normal checksum has been in wide use for  
decades so maybe a new protocol will want to use it, too.

> that required to incrementally update the checksum.)

A translated address that is checksum-equivalant to the address being  
translated from only needs to be computed once. An incremental update  
of the TCP or UDP checksum must be done for every packet, and has the  
issue that it's necessary to look significantly deeper inside packets.  
Not exactly a show stopper in the cases where this can be done  
successfully, but why require it?

> Another way to put this is that I don't see any broad

I know there are people making their services available over IPv6 by  
putting a reverse proxy in front of an IPv4 service. Doing this with  
stateless translation would be a good alternative.

---

From: Rémi Després <[email-masked]>
Date: Mon, 20 Apr 2009 17:24:39 +0200

Dave Thaler  -  le (m/j/a) 4/18/09 1:20 AM:
> * RFC 2765 assumes a (1's complement) checksum-neutral address
> translation.  The current draft assumes a non-checksum-neutral
> address translation.

The point made to justify it seems to me valid and important:
    "Since the ICMP [RFC0792][RFC4443],
    TCP [RFC0793] and UDP [RFC0768] headers consist of check sums which
    include the IP header, the recalculation and updating of the ICMP
    header and the transport-layer headers MUST be performed.  This is
    different from [RFC2765], since [RFC2765] uses special prefix
    (0::ffff:0:a:b:c:d) to avoid the recalculation of the transport-layer
    header checksum."

1's complement checksum neutrality imposes that the checksum of the 2 
IPv6 addresses be the same as that of the 2 v4 addresses.

This creates a complex constraint on values of v6 address bits other 
than those of embedded v4 addresses.

> Personally, I strongly prefer checksum-neutral translation 

The choice seems to be between
- freedom of IPv6 address format, with a necessary detection of whether 
transport is TCP, UDP.
- right to ignore which transport is used (yet having to recognize 
ICMP), and impose for this constraints on Ipv6 addresses

If the only expected IPv6 option is that of fragmentation, as assumed in 
the draft, detecting that transport is TCP or UDP is trivial, in both 
V6toV4 and V4toV6 directions.
Avoiding this detection doesn't seem therefore a reasonable choice if 
the price paid is adding new constraints on IPv6 address formats.

> I believe this can be done, as shown by Margaret for NAT66

Note that in Margaret's NAT66:
- ISP prefixes MUST be "/48 or shorter"
- Subnet numbers MUST be "non-0xFFFF".

I hope you can share the view that these kind of restrictions create a 
relationship between parts of the general architecture that makes it 
more complex to understand and maintain.

> and I
> believe the same concept can work for IPv4<->IPv6 translation).
> Hence I would want the SIIT update to either assume checksum-neutral
> translation if we know of no reason to allow non-neutral, or else 
> allow for either possibility (which would provide better assurance
> that we won't need to update the document in the future).

In my understanding the draft proposal not only is, _as far as users are 
concerned_, CHECKSUM NEUTRAL: it works with checksums of TCP, UDP, SCTP, 
DCCP etc... (This neutrality is not achieved at the IP layer alone, but 
is this of any importance in practice?)

Now the point is that it is ALSO IPv6-address-structure neutral, a 
highly important property IMHO.

I hope to have provided reasons to keep the proposal as is, and  to 
recommend it EXCLUSIVELY. (Allowing for either design would be losing on 
both sides: (1) no single recommended behavior (2) consequently, 
constraint on IPv6 address structures for compatibility with all 
recommended implementations).

Regards,

RD

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Apr 2009 11:27:52 -0400

Iljitsch van Beijnum wrote:
> pseudo-header in the checksum, which is, in my opion, the correct way to
> do things without violating layers. On the other hand, SCTP includes
> address management that would probably fail in the presence of protocol
> translation.
> 
> mapping so only one user can use the protocol. In the case of a
> one-to-one translator that's not exactly a limitation so the only issue
> would be a protocol that uses the normal checksum including
> pseudo-header. Protocols that don't use a checksum (such as tunnels) or
> don't include the pseudo-header should work without trouble if the
> translator translates just the IP header. So I guess this issue isn't
> all that prominent. Then again, the normal checksum has been in wide use
> for decades so maybe a new protocol will want to use it, too.

The "normal" transport layer checksum that has been in wide use for
decades doesn't actually provide very much protection against packet
corruption, in light of current-day e2e bandwidths and the tendency of
applications to transfer more and more data.  So this argues for either
doing away with the transport level checksum (as useless overhead) or
having a more robust checksum.  I would not want to hazard a guess on
which way things will go for future transport protocols.  (Nor would I
want to saddle future transport protocols with an incentive to keep
using the same "normal" checksum.)

> translated from only needs to be computed once. An incremental update of
> the TCP or UDP checksum must be done for every packet, and has the issue
> that it's necessary to look significantly deeper inside packets. Not
> exactly a show stopper in the cases where this can be done successfully,
> but why require it?

I don't get your argument that the translation only needs to be computed
once, because in a stateless translator there's no state kept between
packets to allow the results of previous computations to be stored.
I'll certainly grant that in the (currently rare) case of IP options the
packet inspection is more work to update the transport-level checksum
than it is to update the IP address.

The important point here is that there are lots of different use cases
for v4-v6 NAT, and the best choice of mapping algorithm is going to be
different for different use cases.  Checksum-neutral mapping provides a
useful benefit in some cases, but it does come at a cost.  Consider, for
example, a multihomed network using stateless v4-v6 NATs at its borders.
 With checksum-neutral mapping the relationship between internal and
external addresses, and the relationship between different external
addresses that map to the same internal address, is less obvious than if
a different algorithm were used.  This has the potential to impact DNS,
network management, security (as in packet tracing across NAT
boundaries), etc.

So in summary: yes, it's a useful tool; no, it shouldn't be required
everywhere.

> stateless translation would be a good alternative.

It might be a good alternative.  Or it might be a pain in the a**,
depending on things like the length of the v6 prefix in use, and whether
that v6 prefix were also being used for "native" purposes (and thus
subnetted and routed within that network).  It leads to a tussle between
use of prefix bits for checksum-neutral mapping and use of prefix bits
for subnetting.

Keith

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 20 Apr 2009 19:20:21 +0200

On 20 apr 2009, at 17:24, Rémi Després wrote:

> 1's complement checksum neutrality imposes that the checksum of the  
> 2 IPv6 addresses be the same as that of the 2 v4 addresses.

> than those of embedded v4 addresses.

No, it doesn't. One set of addresses is always constant. Let's say  
those are the source addresses. For the destination address, 96 bits  
of the IPv6 address are also always constant. The remaining bits are  
the IPv4 bits, which cancel out on both sides of the equation. So as  
long as checksum(src v4 32 bits, src v6 128 bits, dst v6 96 bits) = 0  
(or -0) we're in business. This is easily accomplised as follows:

[translator prefix/64][zeroes/16][X/16][IPv4/32]

Where X is the magic ingredient that makes the whole thing checksum to  
0.

> - freedom of IPv6 address format, with a necessary detection of  
> whether transport is TCP, UDP.

> If the only expected IPv6 option is that of fragmentation, as  
> assumed in the draft, detecting that transport is TCP or UDP is  
> trivial, in both V6toV4 and V4toV6 directions.
> Avoiding this detection doesn't seem therefore a reasonable choice  
> if the price paid is adding new constraints on IPv6 address formats.

Simply take advantage of the checksum neutralness if it's there. Then  
operators can decide whether they want or need this.

> - ISP prefixes MUST be "/48 or shorter"

That's because in that case the interface identifier must be  
preserved. In this case, that doesn't apply.

> - Subnet numbers MUST be "non-0xFFFF".

Wrong choice, should be non-0x0000 because al zero bits is pretty much  
impossible to reach using the checksum calculation while all one bits  
is a common result.

> I hope you can share the view that these kind of restrictions create  
> a relationship between parts of the general architecture that makes  
> it more complex to understand and maintain.

No. Overspecify, underimplement. That works. The other way around  
doesn't.

On 20 apr 2009, at 17:27, Keith Moore wrote:

> doing away with the transport level checksum (as useless overhead)

No, it's the link layer checksums that are redundant, see end-to-end  
principle.

> or having a more robust checksum.

Well, requiring that translators be able to rewrite checksums is the  
fastest way to make sure that never happens. Note that we were luckier  
than we deserved to be by the fact that the simple checksum we use is  
incrementally updatable. I shudder to think of the situation where  
NATs would have to rewrite CRC32s in TCP headers.

> packets to allow the results of previous computations to be stored.

Oh right, you could determine these bits algorithmically for each  
packet. You could also simply map the IPv4 address to the IPv6 address  
and use a few bytes more memory, depending what you have more of,  
memory or CPU.

> Checksum-neutral mapping provides a
> a different algorithm were used.

Well, if you go from v4 to v6 96 bits will have to come from  
somewhere. I don't think this is a big deal, especially as address  
management happens on human timescales and packet processing quite  
possibly on nanosecond timescales. Also, non-translated hosts tend to  
use stateless autoconfig which isn't exactly easy on humans.

> So in summary: yes, it's a useful tool; no, it shouldn't be required

I agree with that.

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Apr 2009 15:17:03 +0200

Iljitsch van Beijnum  -  le (m/j/a) 4/20/09 7:20 PM:
> No, it doesn't.

Well, I agree that the word complex, which is subjective, could have 
been avoided. (But the fact that there is a constraint remains.)

> One set of addresses is always constant. Let's say those 
> are the source addresses. For the destination address, 96 bits of the 
> IPv6 address are also always constant. The remaining bits are the IPv4 
> bits, which cancel out on both sides of the equation. So as long as 
> checksum(src v4 32 bits, src v6 128 bits, dst v6 96 bits) = 0 (or -0) 
> we're in business. This is easily accomplised as follows:
> 
> Where X is the magic ingredient that makes the whole thing checksum to 0.

I fully agree with Dave's point made in a previous email:
" As discussed in the WG meeting, I believe this document should be 
independent of the mechanism used to choose the source/dest addresses to 
put into a translated header. This doc shouldn't require updating if 
another mechanism is added in the future, and it should be sufficient to 
apply to SIIT, BIS, NAT64, SAM, IVI, etc. "

Draft-xli-behave-ivi-01 in its sec. 5.1 is open to an evolution where 
port-extended IPv4 addresses are embedded in IPv6 addresses. The 
assumption of 96 constant bits will no longer hold if and when, for 
example, this is done.

>> If the only expected IPv6 option is that of fragmentation, as assumed 
>> in the draft, detecting that transport is TCP or UDP is trivial, in 
>> both V6toV4 and V4toV6 directions.

> That's because in that case the interface identifier must be preserved. 
> In this case, that doesn't apply.

True. (But the fact remains.)

> impossible to reach using the checksum calculation while all one bits is 
> a common result.

Doesn't this remark show that there is some level of complexity in the 
constraints we are discussing.

(Also, would you agree that "pretty much impossible" is not a simple 
concept :-)?)

>> more complex to understand and maintain.

One more point:

RFC 2765 on SIIT, and the draft we comment, both say:
    "When a translator receives an unfragmented UDP IPv4 packet and the
    checksum field is zero the translator MUST compute the missing UDP
    checksum as part of translating the packet."

This rule (unavoidable because UDP null checksums, which are permitted 
in IPv4, are forbidden in IPv6 ), shows that in the case of IPv4/IPv6 
checksum neutrality is not completely feasible at the IP layer (even if 
IPv6 addresses have a favorable format for this).

Regards,

RD

---

From: Fred Baker <[email-masked]>
Date: Tue, 21 Apr 2009 07:16:16 -0700

> than those of embedded v4 addresses.

yes, it does. I'm hoping I will hear an algorithm here for an LIR  
prefix.

---

From: Fred Baker <[email-masked]>
Date: Tue, 21 Apr 2009 07:17:40 -0700

> Where X is the magic ingredient that makes the whole thing checksum  

So the host and the router in front of it have to recognize the type  
of address? The whole point is to do this in a manner that requires as  
few host changes as possible, I had thought.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 21 Apr 2009 18:05:11 +0200

Let's short-circuit this discussion before it spins any further out of  
control...

This issue is that the current translation draft doesn't address the  
checksum issue in enough detail.

What happens with DCCP?

What about unknown protocols which may or may not use the normal  
checksum?

I think if the document goes forward, it should mention this issue and  
specify how unknown protocols are to be handled. Which would be: pass  
them along unmodified.

Also, I would very much like to see mentioned, even if it's only one  
sentence, that if the opertor chooses the IPv6 address that maps to  
the IPv6 source address such that it and the translator prefix  
together checksum to 0, protocols that use the normal checksum, but  
the translator doesn't know how to adjust the checksum for, can  
successfully be translated.

---

From: Xing Li <[email-masked]>
Date: Sun, 26 Apr 2009 07:17:57 +0800

Thanks.

I think we can add the issues of the checksum-neutral in the next 
version of the v4v6-translation document.

(1) For arbitrary addresses, the transport layer checksum must be 
recalculated.
(2) Besides TCP and UDP, other transport layer protocols (e.g. DCCP) 
could be handled based on (details, ...)
(3) For unknown transport layer protocols, the translator should pass 
them along unmodified.
(4) For the stateless one-to-one translation, if the operator chooses 
the IPv6 address that maps to the IPv6 source address such that it and 
the translator prefix together checksum to 0, protocols that use the 
normal checksum, but the translator doesn't know how to adjust the 
checksum for, can successfully be translated.

Anything else is missing?

xing

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 26 Apr 2009 18:21:29 +0200

> could be handled based on (details, ...)

As far as I know, DCCP is the only other transport protocol that uses  
the regular checksum. Would it be possible to add text about how to  
recalculate the DCCP checksum?

> (3) For unknown transport layer protocols, the translator should  
> pass them along unmodified.
> (4) For the stateless one-to-one translation, if the operator  
> chooses the IPv6 address that maps to the IPv6 source address such  
> that it and the translator prefix together checksum to 0, protocols  
> that use the normal checksum, but the translator doesn't know how to  
> adjust the checksum for, can successfully be translated.

Right. I would use text like:

"If an operator chooses an IPv6 address for a host served by a  
translator where the on'es complement addition of the 16-bit words in  
this IPv6 address and those in the translator prefix equal zero  
(0x0000 or 0xffff) then, as far as the checksum is concerned, all  
protocols that use a one's complement checksum will pass through the  
translator successfully, even if the protocol in question is unknown  
to the translator."

Thanks,

Iljitsch

---

From: Rémi Després <[email-masked]>
Date: Mon, 27 Apr 2009 10:47:43 +0200

>> version of the v4v6-translation document.

Agreed.
>> recalculated. (2) Besides TCP and UDP, other transport layer 
>> protocols (e.g. DCCP) could be handled based on (details, ...)
> 
>> pass them along unmodified. (4) For the stateless one-to-one 
>> translation, if the operator chooses the IPv6 address that maps to 

Pushing the analysis further, here is my current understanding of
higher-layer checksum handling in v4-v6 translations:

1. Adjust transport checksum in datagrams if all of:
- v4-to-v6 or v6-to-v4
- first or only fragment of a datagram
- TCP, UDP, or DCCP
- [(Cksm of v6 adds) - (cksm of v4 adds)] is NOT 0xOOOO or 0xFFFF

2. Adjust transport checksum in ICMP error message if all of the following:
- v4-to-v6 or v6-to-v4
- single fragment datagram
- ICMP error message for a TCP, UDP, or DCCP datagram
- [(Cksm of returned v6 adds) - (cksm of returned v4 adds)] is NOT 
0xOOOO or 0xFFFF

3. Compute UDP checksum if all of:
- v4 to v6
- single fragment datagram
- UDP
- v4 transport checksum is 0x0000

4. Compute ICMP checksum, possibly after rule 2. if all of:
- v4 to v6
- ICMP

5. Discard packet if all of the following:
- v4-to-v6
- first fragment of a multi-fragment datagram
- UDP
- v4 transport checksum is 0x0000
- the translator doesn't try to reassemble the datagram, or if it tries 
doesn't succeed

6. Forward without higher layer checksum modification if none of the
above rules applies

There may be remaining errors in this, which better specialists of these
subjects will find, but I suggest that this kind of comprehensive
presentation may help to understand what we really recommend.

NOTE: This leaves a problem if an IPv4  single fragment UDP datagram
with a 0x0000 UDP checksum is discarded after a v4-to-v6 translation.
In this case, the UDP checksum in the returned ICMP error message 
cannot, after a stateless v4-to-v6 translation, be the same as that of 
the original packet.

How important this remark may be is unclear to me. But it identifies an 
advantage, among others, of combining stateless address mappings with 
encapsulations  (where inner packets are unmodified e2e) rather than 
with translations.

Regards,

RD

---

From: james woodyatt <[email-masked]>
Date: Mon, 27 Apr 2009 12:18:47 -0700

On Apr 20, 2009, at 07:36, Iljitsch van Beijnum wrote:
>
> On the other hand, SCTP includes address management that would  
> probably fail in the presence of protocol translation.

Thinking about this some, I don't see why it should fail.  As long as  
the NAT64/DNS64 function operates properly, then SCTP should sail  
along fine without caring what network layer is carrying its packets  
in which address realms.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering