Subject: comments on mech-v2-01

From: "Chirayu Patel" <[email-masked]>
Date: Mon, 10 Nov 2003 18:37:05 +0530

Hello,

Few comments on the draft.

1) A race is triggered when an IPv6 router that has a configured tunnel
   with another router is doing dynamic mtu detection. The outcome of the
   race is that one or more ICMPv6 "packet too big" message might not be
   sent out to an host.

Assume an IPv6 network like:

[H1]-------->[R1]===========>[R2]--------->[H2]

H1, and H2 are IPv6 hosts R1, and R2 are IPv6 routers with a configured
tunnel between them.

and the message flow is:

  1. H1->R1 TCP packet of size 1400.
  2. R1->R2 encapsulated packet of size 1400+20. (R1 is doing PMTU here)
     (Assume 1500 is the link MTU).
  3. Assume one of the IPv4 routers between R1, and R2 send an ICMPv4
     "fragmentation needed" with only 8 bytes of payload.
  4. R1 records the new MTU for the tunnel but does *not* send an ICMPv6
     "packet too big" message with MTU as 1300.
  5. H1->R1 TCP packet of size 1400 (this is a retry)
  6. R1->H1 ICMPv6 "packet too big" with size 1300
  7. H1->R1 TCP packet of size 1400 (this is a retry)
  8. ... (the above cycle might repeat if there are more IPv4 routers
     that send ICMPv4 "fragmentation needed" with 8 bytes of payload)

IMHO, this one can be clarified in the draft so that it does not become a
puzzle for implementors.

9) Link-layer address (which is an IPv4 address) is not meant to be used
   with ND. Is there any reason that the sending (of link-layer address)
   is a "SHOULD NOT", and the receiving is a “MUST ignore”. The sending,
   and the receiving parts should be made consistent with respect to
   link-
   layer address. i.e. sending should be a "SHOULD NOT", and receiving
   should be a "SHOULD ignore”, or sending should be a "MUST NOT", and
   receiving should be a "MUST ignore”. Btw, "NOT" is not a keyword.
   Hence "s/NOT/not".

   "For the purposes of Neighbor Discovery the configured tunnels
   specified in this document are assumed to NOT have a link-layer
   address, even though the link-layer (IPv4) does have address.  This
   means that:

    -   the sender of Neighbor Discovery packets SHOULD NOT include
        Source Link Layer Address options or Target Link Layer Address
        options on the tunnel link.

    -   the receiver MUST, while otherwise processing the neighbor
        discovery packet, silently ignore the content of any Source Link"

Editorial
---------

1) s/For that reason/For that reason,/

---

From: Pekka Savola <[email-masked]>
Date: Mon, 10 Nov 2003 15:23:56 +0200 (EET)

>    receiving should be a "MUST ignore”. Btw, "NOT" is not a keyword.

I had made a note about the same thing in my comments (to-be-written-up).

IMHO, as RFC2461 doesn't even specify the format for an IPv4 Link-layer
address, there is little need for go into this much text here.  I guess
this is a remnant of 6over4 spec which had that definition.

The question is, do we want to care about the fact that 6over4 
unfortunately defined the link-layer option, or do we want to spell out 
the obvious requirement here with "MUST NOT include" and "MUST ignore".

In practice, this has of little relevance if 6over4 is not implemented..
So, maybe we could find a wording that wouldn't require using a lot of 
text and upper-case keywords?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 10 Nov 2003 16:13:28 +0100 (CET)

>      that send ICMPv4 "fragmentation needed" with 8 bytes of payload)

I don't understand how it can repeat. Do you think it can repeat forever?

When the 8-byte payload ICMP errors are sent then R1 will effectively
compute the minimum received (per IPv4 path MTU discovery).

It is true that in the case of 8-byte payload ICMP errors you get at
least two packet drops instead of at least one in the case of a single layer
of MTU discovery (R1 needs to learn the tunnel MTU which causes at least one
packet loss, and then H1 needs to learn the MTU from R1 which causes at
least one packet loss. (And in all cases there can be more than one packet loss
if there are multiple large packets in flight at the same time.)

>    receiving should be a "MUST ignore”.

The reason it was written like this was to not immediately invalidate any
older implementations that might have sent the link-layer address options.
I don't know if there ever were any such implementations.

> Btw, "NOT" is not a keyword.
>    Hence "s/NOT/not".

It's upper case for emphasis, since I can't use bold face. I don't think
this use of upper case voilates any rules.

> 1) s/For that reason/For that reason,/

Noted.

  Erik

---

From: "Chirayu Patel" <[email-masked]>
Date: Tue, 11 Nov 2003 09:20:39 +0530

See below...

On Mon, 10 Nov 2003 16:13:28 +0100 (CET), "Erik Nordmark"
<[email-masked]> said:
> > 1) A race is triggered when an IPv6 router that has a configured
> >    tunnel with another router is doing dynamic mtu detection. The
> >    outcome of the race is that one or more ICMPv6 "packet too big"
> >    message might not be sent out to an host.
> >

No it will not repeat forever. That is why I used "might" in point 8.

> least two packet drops instead of at least one in the case of a single
> layer of MTU discovery (R1 needs to learn the tunnel MTU which causes
> at least one packet loss, and then H1 needs to learn the MTU from R1
> which causes at least one packet loss. (And in all cases there can be
> more than one packet loss if there are multiple large packets in flight
> at the same time.)

Your wording sums it up nicely. My thinking is that such a case is non-
obvious, and we should have a note about it in the draft.

> > 9) Link-layer address (which is an IPv4 address) is not meant to be
> >    used with ND. Is there any reason that the sending (of link-layer
> >    address) is a "SHOULD NOT", and the receiving is a “MUST ignore”.
> >    The sending, and the receiving parts should be made consistent
> >    with respect to link- layer address. i.e. sending should be a
> >    "SHOULD NOT", and receiving should be a "SHOULD ignore”, or
> >    sending should be a "MUST NOT", and receiving should be a "MUST
> >    ignore”.
>
> The reason it was written like this was to not immediately invalidate
> any older implementations that might have sent the link-layer address
> options. I don't know if there ever were any such implementations.

Do you think we should change it now? I prefer "SHOULD NOT" and
"SHOULD ignore".

CP

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Nov 2003 15:57:41 +0100 (CET)

> obvious, and we should have a note about it in the draft.

OK. I'll add that in the section on dynamic tunnel MTU.

> Do you think we should change it now? I prefer "SHOULD NOT" and

Problem is if both ends of a pair of nodes don't satisfy the recommendation
stated in the SHOULDs. In that case things would not interoperate.
Thus I think there has to be a MUST applied to at least one of the sender
and the receiver.

  Erik