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

From: Magnus Westerlund <[email-masked]>
Date: Sat, 21 Mar 2009 07:18:53 -0700

Hi,

I have reviewed the draft and have some comments.

1. Section 2.2, first paragraph:

When it comes to zero UDP checksums we do have a proposal to allow them
also for IPv6/UDP packets draft-eubanks-chimento-6man-00. As this is for
things like Automatic Multicast Tunneling, I guess that we will see
these over a 64 translator. As this changes the assumption about that
zero checksum isn't useful somewhat, do we need to care?

2. Section 2.3:

Should we include required support for the ICMP extension header (RFC
4884) in the document?

3. Section 3, Path MTU Discovery:

I think Dave Thaler talked about the possibility for actually
originating ICMP too big messages that indicate packet sizes that are
less than 1280 bytes. I can understand that this is testing code that
normally aren't executed and thus for interoperability the current
proposed text is much safer. It could allow MTU discovery to work also
for IPv4 paths with MTU lower than 1280.

4. Section 3.1: TOS field

When it comes to the parts that are the diffserv field, there is the
possibility that you like to remapp one set of code-points into another.
Should there be some text recommending that such function is supported,
or is it useless?

5. Section 3.1, and also 2.1:

Next header / Protocol field translation. There are a few that are IPv6
specific shouldn't these be called out specific in this part?

Cheers

Magnus Westerlund
(As individual contributor)

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Fred Baker <[email-masked]>
Date: Sat, 21 Mar 2009 09:08:42 -0700

Thanks

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 22 Mar 2009 11:39:22 +1300

> Should there be some text recommending that such function is supported,

You can legitimately place a diffserv classifier/marker
at pretty much any packet forwarding entity, but it's
an optional (MAY) function, orthogonal to the forwarding. In this
context, a translator is really just a strange forwarding engine.
So I don't see any need to add to what RFC2474 & 2475 say.

    Brian

---

From: Magnus Westerlund <[email-masked]>
Date: Sat, 21 Mar 2009 17:59:44 -0700

> So I don't see any need to add to what RFC2474 & 2475 say.

Brian, maybe an informational reference to this  behavior? The reason I
think it at least should be mentioned is that a 64 translator do create
a new boundary between potentially differently organized diffserv
domains. Thus the need for a diffserv classifier/marker in the
translator seems reasonable.

It is not obvious that implementors will directly realize this. Thus at
least a heads up about the possible need seems warranted.

Cheers

Magnus Westerlund

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 22 Mar 2009 15:40:53 +1300

> least a heads up about the possible need seems warranted.

That works for me.

    Brian

---

From: Xing Li <[email-masked]>
Date: Mon, 23 Mar 2009 09:55:58 +0800

Brian E Carpenter 写道:

Thanks! We will put it on the list of things to fix in the next version.

xing

---

From: Fred Baker <[email-masked]>
Date: Sun, 22 Mar 2009 21:11:34 -0700

> So I don't see any need to add to what RFC2474 & 2475 say.

When it comes to this, although Xing Li has agreed to pick up the  
edit, I'm not so sure. Let me throw out my viewpoint.

My viewpoint is, as you state, that DSCP modifications are generally  
done at the edge of a network, encoding something in the way that the  
next network will understand it. That is something RFC 2474/2475 are  
pretty clear about.

Now, if the translator constitutes a network edge, the implied  
functionality applies. If it doesn't constitute an edge, this is  
unnecessary functionality. I guess I would ask why RFC 2460 (which was  
published within a few days of RFC 2474) didn't need to comment on the  
DSCP other than refer the reader to RFC 2474?

I can see adding a reference to the relevant section of RFC 2474, but  
going into a great level of detail seems to me like a good way to get  
multiple, and as a result diverging, specifications. Diverging  
specifications are  a Bad Thing...

---

From: Xing Li <[email-masked]>
Date: Mon, 23 Mar 2009 21:05:17 +0800

> edit, I'm not so sure. Let me throw out my viewpoint.

I agree with Fred's comments. xing

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Mar 2009 03:34:07 +1300

Fred - let's wait for the revised text, since I don't
see a difference between what you say and what Magnus
said. I agree of course that there is no new normative
text needed (as there wasn't for tunnels, which is
why RFC2983 is Informative). Pretty much all that is needed
is 'By the way, check out 2474/2475, because this could
also be a diffserv domain boundary.'

   Brian

On 2009-03-23 17:11, Fred Baker wrote:
> When it comes to this, although Xing Li has agreed to pick up the edit,
> I'm not so sure. Let me throw out my viewpoint.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 23 Mar 2009 07:58:12 -0700

> next network will understand it. That is something RFC 2474/2475 are

Agreed, but can you assume that both IPv4 and IPv6 address domains are
going to use the same DSCP codepoint plan? If they don't then you need
to have the reclassifier independent if the translator is sitting on a
edge or not.

> specifications are  a Bad Thing...

I am fine with simply pointing out the potential need for a DSCP
reclassifier in the translator.

Cheers

Magnus Westerlund

---

From: Fred Baker <[email-masked]>
Date: Mon, 23 Mar 2009 08:12:35 -0700

> to have the reclassifier independent if the translator is sitting on a

I don't see any reason to automatically assume one or the other. If  
the two domains are run by a common administration, I would be very  
surprised to see the administration have different sets of rules. If  
they are different administrations, they might very well have  
different services. The question isn't whether they run IPv4, IPv6, or  
IPv16 for that matter; the question is the administrative boundary.

Which is what RFC 2474/2475 say and the reason that documents that  
focus on IP headers simply point to them.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 23 Mar 2009 08:44:04 -0700

Fred Baker skrev:
> I don't see any reason to automatically assume one or the other. If the
> two domains are run by a common administration, I would be very
> they are different administrations, they might very well have different
> services. The question isn't whether they run IPv4, IPv6, or IPv16 for
> that matter; the question is the administrative boundary.

Agreed, but the border can exist, that was my point.

> 
> Which is what RFC 2474/2475 say and the reason that documents that focus
> on IP headers simply point to them.
> 

Also agreed!

Cheers

Magnus Westerlund

---

From: Fred Baker <[email-masked]>
Date: Mon, 23 Mar 2009 13:07:09 -0700

> zero checksum isn't useful somewhat, do we need to care?

I see that as a question for 6man. In a translator, either we require  
a checksum in UDP, or we don't, in my view. Please don't ask me to try  
to determine whether the UDP message is using some specific protocol.  
At least one viewpoint would suggest that RFC 2460's insistence on the  
checksum was an unauthorized change to a protocol not under discussion.

Question for you, here. Are you asking us to flag the fact that a UDP  
datagram transiting from an IPv4 network to an IPv6 network may  
require a checksum calculation if it is zeroed? Personally, I would  
prefer to see that done on the host or not at all. Think in the  
context of gigabit links. I would rather give the translator the  
option of discarding the datagram and telling the administrator to  
reconfigure his hosts.

> Should we include required support for the ICMP extension header (RFC

Tell me: is there anything that makes a strong statement about the  
implementation of RFC 4884 in other systems? It seems like the level  
of requirement here would be the same as the level of requirement in  
other systems.

I might be willing to see it as a "SHOULD". From my perspective (being  
one of the editors who worked with normative language prior to Scott's  
RFC defining the terms), I use "MUST" when the failure to do something  
breaks something, and I try to say what broke. I use SHOULD when it is  
something I would like to require but don't think failure to implement  
actually breaks anything. I use MAY when there are those who care but  
I'm not one of them.

If I say that the implementer MUST implement 4884, then I think I am  
duty bound to detail a section telling him how, and I think I am also  
bound to tell him what will break if he doesn't - and I think that is  
"RFC 4884 functionality". So in my mind, "MUST" doesn't fit. If there  
is no statement to the effect that folks SHOULD implement RFC 4884 in  
other places this one is an odd first choice in upping the ante. I  
could imagine simply pointing to the document and making no  
requirement statement at all.

Give me something solid to work from here?

> for IPv4 paths with MTU lower than 1280.

In my mind, the MTU is a number configured on an interface; if the  
interface is configured to not accept 100 byte packets we should  
respond ICMP TOO BIG when we get a 100 byte packet. The question isn't  
whether we generate the message in such a case, it's whether we allow  
the network administrator to configure that small of a number.

What would you like me to do with this comment?

> Should there be some text recommending that such function is  

As we discussed separately, the question is one of an administrative  
boundary. At most, we should point to RFCs 2474 and 2475 and indicate  
that in cases where the translator is implemented on a boundary where  
DSCP translation is appropriate the implementor should enable that to  
happen.

> specific shouldn't these be called out specific in this part?

OK. Note that they weren't in the document that these sections are  
inherited from and nobody has complained about that. Could you list  
the ones you think are important to note?

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 23 Mar 2009 14:56:42 -0700

Please see my comments inline.

Fred Baker skrev:
> I see that as a question for 6man. In a translator, either we require a
> checksum in UDP, or we don't, in my view. Please don't ask me to try to
> determine whether the UDP message is using some specific protocol. At
> least one viewpoint would suggest that RFC 2460's insistence on the
> datagram transiting from an IPv4 network to an IPv6 network may require
> a checksum calculation if it is zeroed? Personally, I would prefer to
> see that done on the host or not at all. Think in the context of gigabit
> links. I would rather give the translator the option of discarding the
> datagram and telling the administrator to reconfigure his hosts.
> 

This was primarily an observation about that the assumptions that this
spec uses to motivate to drop fragments with zero checksum. Forcing
reassembly in the translator do seems to be way to heavy a solution.

So no change in my mind.

> implementation of RFC 4884 in other systems? It seems like the level of
> requirement here would be the same as the level of requirement in other
> systems.

The following documents seems to have references to RFC 4884:

draft-atlas-icmp-unnumbered-06
rfc4950 (ICMP Extensions for Multiprotocol Label Switching)
draft-shen-udp-traceroute-ext-01
draft-ietf-behave-nat-icmp-12
draft-ietf-shim6-proto-12
draft-wing-behave-nat-control-stun-usage-05
draft-wood-dna-link-properties-advertisement-01
draft-frejborg-hipv4-01

My understanding is that extensions are optional to use, and volunteer
for end-systems to support them.

> "RFC 4884 functionality". So in my mind, "MUST" doesn't fit. If there is
> no statement to the effect that folks SHOULD implement RFC 4884 in other
> places this one is an odd first choice in upping the ante. I could
> imagine simply pointing to the document and making no requirement
> statement at all.

I think you are rushing to level of support before discussing what it
actually means to handle ICMP extensions.

> Give me something solid to work from here?

A translator can support header extensions by correctly fill in the
length field modification it applies when translating the addresses. The
translation should not go beyond the length field for the original
datagram field to avoid changing the extension itself.

If the ICMP extension isn't translated I think two cases exist:

1. That the translated packet is created from scratch and the length
field never is filled in. Then an ICMP extension will result in that it
will be treated as part of the original datagram field.

2. If the IP payload is copied and then modified then the length field
will be unmodified while the original datagram field will become longer
by the address translation from v4->v6. Thus cutting off the end of the
original datagram field for ICMP extension aware receivers.

What I haven't grasped is if anything in the extension part actually
needs translation. Hopefully not.

I think supporting the length field modifications are straight forward
and avoids breaking things. Thus I would argue for MUST.

> interface is configured to not accept 100 byte packets we should respond
> ICMP TOO BIG when we get a 100 byte packet. The question isn't whether
> we generate the message in such a case, it's whether we allow the
> network administrator to configure that small of a number.
> 

I think we have different views on what MTU is, I probably should add
Path before MTU to be clear. But that varies with the peer IP address in
my mind, yes it can't go above the interface MTU, but it definitely can
be smaller based on tunnels, etc, on the path.

The question I do like to get community feedback that I don't haven't
bee answered is:

Is sending IPv6 packet to big messages with a value lower than 1280
bytes a possibility as better working alternative to do IPv4
fragmentation by sending packets with DF=0?

> DSCP translation is appropriate the implementor should enable that to

Agreed

> inherited from and nobody has complained about that. Could you list the
> ones you think are important to note?
> 

The below ones are noted in the IPv6 parameters registry:
http://www.iana.org/assignments/ipv6-parameters

5.a. Header types

        00 = Hop-by-Hop Options
        41 = ipv6
        43 = Routing
        44 = Fragment
        51 = Authentication
        60 = Destination Options
        50 = Encapsulating Security Payload
        xx = Upper Layer Header
        58 = Internet Control Message Protocol (ICMP)
        59 - no next header

   For the "xx" values see the list of protocol numbers for the values
   to use for the upper layer '

For the protocol registry
http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

The document accounts for Hop-by-hop, Routing, destination options are
already accounted for by saying that they are not handled.

IPv6 and ESP are simply payloads for the transport and shouldn't have
any issues.

AH (Authentication) will be broken by the translator. That might even be
worth saying that it shall be dropped to not waste resources? Or is it
better to deliver them to the end host and have the AH drop them?

No Next header could potentially be an issue. The question from my part
is if anyone knows what happens if a IPv4 packet contains value 59 in
its Protocol field?

Cheers

Magnus Westerlund

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 23 Mar 2009 18:19:58 -0700

...
> needs translation. Hopefully not.

At this time, none have been defined that need translation.  We
skirted around this in draft-ietf-behave-nat-icmp with

   ICMP Error payload may contain ICMP extension objects ([ICMP-EXT]).
   NATs are encouraged to support ICMP extension objects. At the time
   of this writing, the authors are not aware of any standard ICMP
   extension objects containing realm specific information.

unfortunately if, in the future, someone puts 'realm specific' 
information into an extension, we have no way to identify it
and know it needs to be NATted.  I don't see a solution to that,
though.

-d

---

From: Dave Thaler <[email-masked]>
Date: Tue, 24 Mar 2009 15:40:50 -0700

Magnus wrote:
[...]
> >> for IPv4 paths with MTU lower than 1280.
[...]

Magnus,

The text I referred to is from RFC 2460 section 5, which states:

   In response to an IPv6 packet that is sent to an IPv4 destination
   (i.e., a packet that undergoes translation from IPv6 to IPv4), the
   originating IPv6 node may receive an ICMP Packet Too Big message
   reporting a Next-Hop MTU less than 1280.  In that case, the IPv6 node
   is not required to reduce the size of subsequent packets to less than
   1280, but must include a Fragment header in those packets so that the
   IPv6-to-IPv4 translating router can obtain a suitable Identification
   value to use in resulting IPv4 fragments.  Note that this means the
   payload may have to be reduced to 1232 octets (1280 minus 40 for the
   IPv6 header and 8 for the Fragment header), and smaller still if
   additional extension headers are used.

draft-baker-behave-v4v6-translation-02 section 3 already refers to this:

   An IPv6 link has to have an MTU of 1280 bytes or greater.  The
   corresponding limit for IPv4 is 68 bytes.  Thus, unless there were
   special measures, it would not be possible to do end-to-end path MTU
   discovery when the path includes an translator since the IPv6 node
   might receive ICMP "packet too big" messages originated by an IPv4
   router that report an MTU less than 1280.  However, [RFC2460]
   requires that IPv6 nodes handle such an ICMP "packet too big" message
   by reducing the path MTU to 1280 and including an IPv6 fragment
   header with each packet.  This allows end-to-end path MTU discovery
   across the translator as long as the path MTU is 1280 bytes or
   greater.  When the path MTU drops below the 1280 limit the IPv6
   sender will originate 1280 byte packets that will be fragmented by
   IPv4 routers along the path after being translated to IPv4.

I would only suggest a trivial change here to help the reader, namely
change "[RFC2460]" to "[RFC2460] section 5".

-Dave

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 24 Mar 2009 16:16:06 -0700

Thanks Dave,

I apparently misinterpreted the text that you quote. It might be the
paragraph that follows that through me off:

   The only drawback with this scheme is that it is not possible to use
   PMTU to do optimal UDP fragmentation (as opposed to completely
   avoiding fragmentation) at sender since the presence of an IPv6
   Fragment header is interpreted that is it OK to fragment the packet
   on the IPv4 side.  Thus if a UDP application wants to send large
   packets independent of the PMTU, the sender will only be able to
   determine the path MTU on the IPv6 side of the translator.  If the
   path MTU on the IPv4 side of the translator is smaller then the IPv6
   sender will not receive any ICMP "too big" errors and can not adjust
   the size fragments it is sending.

By having this discussion it is implied that we should at least discuss
changing the IPv6 spec. I think that is unnecessary. We have to live
with this.

Magnus

-- 

Magnus Westerlund