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

[Magnus Westerlund <[e-mail]>]

Please see my comments inline.

Fred Baker skrev:
> 
> On Mar 21, 2009, at 7:18 AM, Magnus Westerlund wrote:
> 
>> 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?
> 
> 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.
> 

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.

>> 2. Section 2.3:
>>
>> Should we include required support for the ICMP extension header (RFC
>> 4884) in the document?
> 
> 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.

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.

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

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.

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

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?



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

Agreed

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

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

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------