Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-00

From: Fred Baker <[email-masked]>
Date: Sat, 25 Jul 2009 08:03:07 +0200

On Jul 25, 2009, at 2:06 AM, Dave Thaler wrote:

> A marked up copy with my comments is attached.
>
> Some high-level points:
>
> * This document says it is intended to obsolete RFC 2765, but then
>  normatively references RFC 2765.  We can't have it both ways.  I
>  believe it should not normatively reference RFC 2765.

np

> * Unless this document can argue (or reference something else that
>  argues) that some particular piece of SIIT is harmful, I would
>  assert that the goal should be that an implementation of RFC 2765
>  should be compliant to this document (at least to the given piece
>  of it in question).

In my opinion, the argument against the magic prefix is that it is  
harmful, for the same reasons that a site-local prefix was deemed  
harmful, deprecated, and replaced.

> * As currently written, the draft seems to preclude checksum-neutral
>  address-translation algorithms that avoid any transport layer
>  header inspection on stateless translators.  I don't believe this
>  should be precluded (and in fact I'd rather see them be at least
>  a SHOULD or preferably even a MUST for stateless translation).
>  Currently this is a regression from RFC 2765.

They only work with a magic prefix, however. Operational experience  
suggests that the checksum is far less of an issue and being able to  
route effectively is far more of an issue.

> * Section 2.2 requires the translator to be able to compute checksums
>  over the entire packet, where section 2.5 makes it be a MAY, which
>  seems to be a contradiction.  Given the opportunity for CPU DOS
>  attacks against even stateless translators (which should be added
>  to the Security Considerations section), I don't believe it should
>  be a MUST.

We'll take a look at that.

Thanks for the comments.

> -Dave
> <draft-ietf-behave-v6v4-xlate-00.pdf>

---

From: Dave Thaler <[email-masked]>
Date: Sat, 25 Jul 2009 06:06:46 +0000

Fred Baker writes:
[...]
> They only work with a magic prefix, however.

No, checksum neutrality doesn't require a magic prefix.

It only requires 16 bits of space for including checksum compensation.
The NAT66 draft for example had no magic prefix but was checksum
neutral, and the same can be applied to any LIR prefix for 6/4
translation, provided it's less than about 80 bits long.

-Dave

---

From: Fred Baker <[email-masked]>
Date: Sat, 25 Jul 2009 09:23:13 +0200

> translation, provided it's less than about 80 bits long.

That becomes a pretty violent change to RFC 4291, as a host by  
definition has not an address but an address-with-mask, and it can't  
be expressed as a CIDR prefix. Remember that one of the objectives  
here is to not change the host's IPv6 implementation...

---

From: Christian Huitema <[email-masked]>
Date: Sat, 25 Jul 2009 07:31:48 +0000

> here is to not change the host's IPv6 implementation...

In fact, the checksum requirement can be satisfied in many ways. Any function that chooses an IPv6 address such as:
        IPv6 = mapping(IPv4)
And     Checksum(IPv6) = Checksum(IPv4)
Will meet the checksum criteria.

For example, I could pick a host ID composed of 56 random bits + 16 bits computed so the checksum of the IPv4 address map that of the IPv6 address, and then enter the corresponding mapping in a table.

Not that I would recommend doing that.

-- Christian Huitema

---

From: Rémi Després <[email-masked]>
Date: Sat, 25 Jul 2009 09:31:58 +0200

Dave, Fred,

In a June 10 mail, I proposed the following description of what could  
be, in my understanding, a recommended checksum behavior.
It received no answer but is still relevant IMHO.
It lists test to be done before deciding that transport checksum can  
be left as is (checksum-neutrality).

Here is what it was (where adds stands for addresses, and vX-to-vY  
stands for the direction of translation from vX to vY):

<<<
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.

Thoughts?

Regards,
RD

Le 25 juil. 09 à 08:06, Dave Thaler a écrit :

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

---

From: Dave Thaler <[email-masked]>
Date: Sun, 26 Jul 2009 10:45:09 +0000

> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]]
> Sent: Saturday, July 25, 2009 12:23 AM
> To: Dave Thaler
> Cc: [email-masked]; [email-masked]; 'Behave WG'
> Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-00
>
>

Huh?  There's no change to RFC 4291 nor to the /64 subnet prefix length.
It's how you generate the interface identifier (e.g. in a translator
if it's representing an IPv4 host, or in a DHCPv6 server or whatever else
you use to assign addresses to IPv6 nodes for stateless translation).

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Sat, 25 Jul 2009 00:06:36 +0000

Some high-level points:

-Dave