Subject: (ngtrans) more comments on draft-ietf-ngtrans-mech-v2-00.txt

From: [email-masked]
Date: Wed, 18 Sep 2002 16:20:39 +0900

i think this document should better be splitted into two:
	- IPv6-over-IPv4 configured tunnelling (bidirectional)
	- dual IP layer operation
	these issues are completely separate, and the split will simplify
	the document very much.

	btw, here are summary of issues raised so far.  hope this is helpful.

itojun

	Should 6to4 be mentioned?
	Should all DNS stuff be removed?
		duplicate of addr-select
		some discussion on mailing list

	wording nits, section reordering (templin)
	unidir tunnel really worth a mention? (pekka)
	is TOS field handling friendly with DSCP? (pekka)
	more security consideration (pekka, alain, itojun)
		injecting packet into egress point (anonymizer) 
		auto tunnel will be open relay of packet
	tunnel MTU/MRU needs to be specified, PMTUD rule should be simplified (itojun)
		referenced from 6to4/ISATAP documents, should it be separate?
	biased to dual stack operation, should talk about IPv6-only operation (alain)
	real meaning of "dual stack"? (alain)
	ingress filtering at tunnel egress and IPv4 anycast address (alain)
	how about separating document into two? (itojun)
		tunnel doc, and dual stack doc

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Sep 2002 12:06:58 +0200

>         these issues are completely separate, and the split will simplify

I'm not sure I agree. Firstly this update is badly needed as an RFC,
and I don't think we should accept the delay that splitting it would
cause. Secondly, I think it's very useful to have a single document
that covers all the basic, non-exotic mechanisms which we agreed on
in around 1995 and that really haven't changed.

>         Should 6to4 be mentioned?

I don't think so. Even though it's deployed and used, it's
still not a basic mechanism.

>         is TOS field handling friendly with DSCP? (pekka)

Not quite. There should be an informational reference to 
RFC 2983 (Differentiated Services and Tunnels). Exactly what
an encapsulator or decapsulator should do with the TOS field
depends on deployment scenarios, so it needs to be neutral:

In the encapsulator section:
OLD:
        Type of Service:

                0. [Note that work underway in the IETF is redefining
                the Type of Service byte and as a result future RFCs
                might define a different behavior for the ToS byte when
                tunneling.]

NEW:
        Type of Service:

                The considerations documented in [RFC 2983] apply.
                The default value MUST be 0.

And in the decapsulator section:

OLD: 
   [Note that work underway in the IETF is redefining the Type of
   Service byte and as a result future RFCs might define a different
   behavior for the ToS byte when decapsulating a tunneled packet.] 

NEW:
   For the Type of Service byte, the considerations documented in 
   [RFC 2983] apply.

>                 tunnel doc, and dual stack doc

     Brian

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 20 Sep 2002 11:20:50 +0200 (CEST)

> 	these issues are completely separate, and the split will simplify

That might make sense, but it would probably prevent advancing to draft
standard at this point in time.
(The current document is just RFC 2893 with things deleted, thus it
could be put forth for draft standard.)

Up to the WG chairs to decide which path to take.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 20 Sep 2002 12:04:48 +0200 (CEST)

> 	tunnel MTU/MRU needs to be specified, PMTUD rule should be simplified

Here is a proposal to improve interoperability by making the language
in the specification tighter.

1. Add a minumum MRU that all implementations MUST handle.
   Currently there is no such requirement, but one can perhaps infer
   from the specification that 64kbyte is the number.
   We can debate the actual number forver, but I suspect the debate
   will range between 1k and 4k.

2. Clarify that the dynamic path MTU mechanism in section 3.2 is OPTIONAL
   but if it is implemented it should follow the rules in section 3.2.

3. State that when the dynamic PMTU is not implemented the sender MUST NOT
   by default send IPv6 packets larger than "max MTU" into the tunnel.
   We can debate this number.

4. State that implementations MAY have a knob by which the "min MRU" and the  
     "max MTU" can be set to larger values on a tunnel by tunnel basis,
   but that the defaults MUST be the above numbers.

The biggest help for interoperability is nailing down the MTU/MRU so that out
of the box things will interoperate even with the optional dynamic pmtu
mechanism isn't used.

  Erik

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Mon, 23 Sep 2002 10:43:18 +0900 (JST)

> of the box things will interoperate even with the optional dynamic pmtu

	i think i agree with the above.  could you clarify what is the
	difference between "min MRU" in (1) and "max MTU" in (3)?

itojun

---

From: Robert Elz <[email-masked]>
Date: Mon, 23 Sep 2002 16:29:57 +0700

Date:        Mon, 23 Sep 2002 10:43:18 +0900 (JST)
    From:        [email-masked] (Jun-ichiro itojun Hagino)
    Message-ID:  <[email-masked]>

  | 	i think i agree with the above.  could you clarify what is the
  | 	difference between "min MRU" in (1) and "max MTU" in (3)?

Erik and I started to have a bit of a discussion about this at the end
of last week...   Unfortunately, this list's absurd Reply-To header
meant that my message to him was sent only to him, and not to the list.

The (3) messages that ended up being off list are going to be resent to
the list, after which it was Erik's turn to reply once again...

Then, over the weekend, some net difficulties meant I didn't get a chance
to send the messages in question.   I will do that now.   If you get to see
some messages with slightly messed up headers (and perhaps some wild looking
dates) this will be the cause.

kre

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 23 Sep 2002 15:46:58 +0200 (CEST)

> 	difference between "min MRU" in (1) and "max MTU" in (3)?

We could pick a MRU of around 4k, and a MTU of 1500 bytes.
This means that implementations that don't do the optional dynamic
MTU would send 1500 bytes, but that all receivers would be able
to cope with dynamic MTU senders that send 4k packets.
(Note that those 4k packets would not be fragmented by IPv4 if folks follow
the specification, but I think the notion of MRU should apply whether or
not the packets were fragmented.)

  Erik

---

From: Robert Elz <[email-masked]>
Date: Mon, 23 Sep 2002 21:47:32 +0700

Date:        Mon, 23 Sep 2002 15:46:58 +0200 (CEST)
    From:        Erik Nordmark <[email-masked]>
    Message-ID:  <[email-masked]>

  | (Note that those 4k packets would not be fragmented by IPv4 if folks follow
  | the specification, but I think the notion of MRU should apply whether or
  | not the packets were fragmented.)

Absolutely.

A 6to4 receiver has to implement IPv4 reassembly anyway - it is an IPv4
host (for this purpose - packets are addresses to it).

Further, IPv6 requires it, as it requires any link level that can't handle
1280 byte packets as a unit to implement some kind of link level frag/reass
method, so 1280 is supported.

As a link level, IPv4 only guarantees support for 68 byte packets (which would
be an IPv6 packet size of 48 bytes) so the IPv6 spec requires that 
fragmentation and reassembly be done where necessary.

Of course, wherever possible, we want to avoid it - and since in today's
internet, packets <= 1500 bytes are rarely fragmented, having 6to4
assume that is reasonable (provided DF isn't set for any packet with
an IPv6 size of 1280 or less - which isn't to say it should be set at
all, no matter the size).

So, sending with an IPv6 MTU < = 1480 is the obvious thing to do.

The point of setting a required MRU larger than that, is just so nodes
can know that the packet will be received if the day comes when that
"1500" we currently assume becomes bigger.

Note - the only change required to an implementation is that it be able to
handle larger packets, or if that will always require reassembly (the node
has no interfaces with an MTU around 4K or bigger) then Christian's
"peek in the reassembly queues" method will also work.

As a practical matter, the node doesn't need to anticipate receiving such
packets (doesn't need to budget lots of ram for reassembly queues) as
none should actually be received anytime soon (because of having the MTU
set lower in all sensible cases), and because even if a node does send
bigger, once received, the 6to4 node will just be sending an ICMP "too
big" anyway - as it won't have any way to transmit an IPv6 packet that is
that big (we already assumed no local interfaces with an MTU this big).

kre