Subject: RE: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt

From: "Dave Thaler" <[email-masked]>
Date: Mon, 24 Nov 2003 10:30:03 -0800

This is the issue I mentioned again in Minneapolis...

From draft-ietf-v6ops-mech-v2-01.txt:
> 
> 3.2.1.  Static Tunnel MTU
> 
>    A node using a static tunnel MTU MUST limit the size of the IPv6
>    packets it tunnels to 1280 bytes i.e., treat the tunnel interface
as
>    having a fixed interface MTU of 1280 bytes.  An implementation MAY
>    have a configuration knob which can be used to set a larger value
of
>    the tunnel MTU than 1280 bytes, but if so the default MUST be 1280
>    bytes.  A larger fixed MTU should not be configured unless it has
>    been administratively ensured that the decapsulator can reassemble
>    packets of that size.  Care should be taken when manually
configuring
>    large tunnel MTUs to only do so when the MTU of the IPv4 path to
the
>    tunnel endpoint is large to avoid causing excessive fragmentation.

Here's a scenario which may become common:

A mobile node has
1) an Ethernet interface connected to a v4-only network
2) some type of IPv6 over IPv4 tunnel that follows this spec,
    where the IPv4 address used for encapsulation is the address 
    on interface 1.
3) an IPv6 over IPv6 tunnel to its home agent to support mobile IPv6,
    where the IPv6 address used for encapsulation (i.e. its
care-of-address)
    is the IPv6 address on interface 2.  With route optimization
optional, 
    one common case is where the majority of communication would be over

    this interface (reverse tunneled).

Interface 3's MTU can be no smaller than 1280, so let's assume it's
1280.
If interface 2's MTU is 1280, then each 1280-byte packet being
reverse-tunneled out interface 3 must undergo fragmentation after being 
encapsulated to go out interface 2.  As a result, excessive
fragmentation 
on most data packets results.

If the mobile node changes the MTU of interface 2 to be some larger
value,
then gratuitous fragmentation can be avoided.  Obviously if the IPv4
path MTU isn't large enough to support 1280 + both encapsulations you'll

get fragmentation regardless.  But in general the mobile node doesn't
know ahead of time whether a larger MTU will cause fragmentation
whereas it does know that using 1280 WILL cause fragmentation.

The current text is ambiguous as to whether it would be legal or
illegal for the mobile node to (say) use a larger MTU on interface 2 
(with IPv4 DF bit clear) automatically upon being configured to be a 
mobile node.  Is the intent that this is illegal?  If so, this 
seems harmful, and it would be good to point out that excessive 
fragmentation will occur for mobile nodes.  If this is not the 
intent, then the language should be clarified.

Also on the sentence:
> A larger fixed MTU should not be configured unless it has
> been administratively ensured that the decapsulator can reassemble
> packets of that size.

RFC 2460 section 5 says:
>  A node must be able to accept a fragmented packet that, after
>  reassembly, is as large as 1500 octets.

Is this statement sufficient "administrative assurance" that the 
decapsulator can reassemble packets up to 1500 octets in size?

If so, I'd propose rewording as:
> A fixed MTU larger than 1500 bytes should not be configured unless it
has
> been administratively ensured that the decapsulator can reassemble
> packets of that size.

-Dave

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 25 Nov 2003 03:58:10 +0900 (JST)

> > been administratively ensured that the decapsulator can reassemble

	the above sentence encourages unmatched/unnegotiated MTU/MRU
	configuration.  i saw problems with these in the past so i'm skeptical
	with the suggested change.

itojun

---

From: Fred Templin <[email-masked]>
Date: Mon, 24 Nov 2003 14:20:14 -0800

I agree with certain elements of what both Dave and Itojun are
saying. I believe that RFC 2460, section 5 (as quoted by Dave)
provides sufficient administrative assurance that an IPv6-in-IPv4
tunnel decapsulator can reassemble packets up to 1500 octets. The
only problem with Dave' s proposal is that, with no prior negotiation,
the encapsulator has no way of knowing whether its tunneled packets
will be fragmented by the IPv4 network, which could lead to black
holes and/or poor performance. Reasons:

  1) certain middleboxes drop IPv4 fragments; sometimes
     sending only the first fragment on to the final destination

  2) Fragmenting IPv4 packets causes slow-path processing in
     some middleboxes

  3) some middleboxes may not implement IPv4 fragmentation
     at all

Itojun seems to be suggesting that an initial negotiation is needed to
determine the MRU, and while learning the true MRU would clearly
be a good thing it seems to me that the 1500 byte minimum MRU
indicated by Dave is a reasonable assumption, and the true MRU
will most likely be discovered in the TCP MSS negotiation anyway.

However, I see a clear and necessary purpose for an initial negotiation,
which is to determine a lower bound on the minimum IPv4 link MTU
for the links on the IPv4 path from the encapsulator to the decapsulator.
Discovering the minimum IPv4 link MTU is necessary to determine the
maximum IPv6 packet/fragment size that can traverse the tunnel without
incurring IPv4 fragmentation.

So, I believe the initial negotiation is necessary and the best mechanism
to support this is sending an IPv6 Router Solicitation and getting an IPv6
Router Advertisement back. (My writings have talked about using RS/RA
exhanges for MTU negotiations among other purposes for a long time now.)
Reasons why using the RS/RA mechanism is best:

  1. We can pad the RSs to a particular size (e.g., 512 bytes, 1280 bytes,
    etc.) to "plumb" the IPv4 path MTU and get an initial lower bound
    on the minimum IPv4 link MTU.

  2. We can verify that any RAs received come from a trusted router
    using, e.g., SEND or some other trust mechanism so that we will
    not be vulnerable to learning bad MTU/MRU information from
    malicious nodes.

I talk about this particular approach in my current document on
Dynamic MTU determination for IPv6-in-IPv4 tunnels found at:

  http://www.ietf.org/internet-drafts/draft-templin-tunnelmtu-04.txt

but the approach can be augmented by including the decapsulator's
MRU in the RA messages it returns. This might require adding a
new type of MRU option, such as the ones I have discussed in
some of my past works.

Fred
[email-masked]

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 25 Nov 2003 07:48:02 +0900 (JST)

> Reasons why using the RS/RA mechanism is best:

	both end of the tunnel could be router, so it looks weird for me that
	a router to send RS/receive and process RA (other than the validation
	rule in RFC2462).

itojun

---

From: Fred Templin <[email-masked]>
Date: Mon, 24 Nov 2003 15:32:35 -0800

Itojun,

Nodes may act as hosts on some interfaces and routers on other
interfaces. They may also act in different turns as routers and hosts
on the same interface. I see nothing in RFC 2461 that precludes such
"hybrid" nodes from sending RSs and processing RAs.

In fact, the second-to-last paragraph of RFC 2461, section 6.2.7
("Router Advertisement Consistency") says:

   "Note that it is not an error for different routers to advertise
   different sets of prefixes.  Also, some routers might leave some
   fields as unspecified, i.e., with the value zero, while other routers
   specify values.  The logging of errors SHOULD be restricted to
   conflicting information that causes hosts to switch from one value to
   another with each received advertisement."

So, if router A has good reason to believe that router B advertises
a different set of prefixes, I see nothing unusual about A sending
RSs to B (and getting RAs back from B) to discover the different
prefixes.

Fred
[email-masked]

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 25 Nov 2003 10:10:31 +0900 (JST)

> RSs to B (and getting RAs back from B) to discover the different

	i guess i mentioned it in the past, if we allow routers to advertise
	different set of prefixes (which is the case now with RFC2462) and
	allow routers to autoconfigure themselves with RA, we go into
	bootstraap problem when router reboots.  i consider autoconfiguring
	router is a dangerous idea, and "hybrid router" idea is too.

itojun

---

From: Fred Templin <[email-masked]>
Date: Mon, 24 Nov 2003 17:40:41 -0800

Hmm - you seem to be assuming that the only reason for router A
to send an RS to router B (and get an RA back) is for the purpose
of autoconfiguration (i.e., RFC 2462, section 5.5.3). I'm not
assuming that at all.

I believe it is useful in some cases for router A to discover the prefixes
being advertised by router B w/o necessarily seeking to autoconfigure
addresses based on those prefixes. (RFC 2461, section 6.2.7 gives one
such example.)

Fred
[email-masked]

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 25 Nov 2003 11:03:15 +0900 (JST)

> addresses based on those prefixes. (RFC 2461, section 6.2.7 gives one

	if
	- A advertises P1/64 and P2/64, and has P1:id1 and P2:id2 as address
	- B advertises P3/64, and has P3:id3 as address
	onto the same ethernet broadcast domain, A would think that P3::/64 
	as off-link, and sends packets to P3:id3 to default route
	(instead of performing NS/NA).  we can cook up more complex example
	like this, but i wouldn't bother.  we really need simplification here.

	i personally would like to see RFC2461 section 6.2.7 to be updated to
	require routers to advertise consistent prefix information.  we can
	consider it an operational issue (instead of implementation issue) so
	backward compatibility should not matter that much.

itojun

---

From: Fred Templin <[email-masked]>
Date: Tue, 25 Nov 2003 05:05:38 -0800

Itojun,

I think I understand your concern now. There will certainly be "ROUTERS"
that send "ROUTER ADVERTISEMENTS", and they will contain information
about attached *prefixes* and in many cases autoconfig parameters. But, 
I'm not
talking about those; I'm talking about "routers" that send "router 
advertisements"
that contain information about attached *addresses* (locators?) and in most
cases no autoconfig or prefix information at all.

So, you are concerned with what would happen if I get a "ROUTER
ADVERTISEMENT" when I was instead expecting to receive a "router
advertisement" - correct? I think a good way to avoid the confusion would
be to use the mechanisms specified in:

http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-02.txt

In fact, let's see that this gets pushed through to standard asap.

Thanks - Fred
[email-masked]

---

From: Fred Templin <[email-masked]>
Date: Tue, 25 Nov 2003 06:03:59 -0800

The v6ops discussion from the 'draft-ietf-v6ops-mech-v2-01.txt' thread
took on an interesting twist that I felt warranted a new subject heading.

RFC 2461 specifies the behavior of traditional routers (i.e., "ROUTERS").
"ROUTERS" typically advertise autoconfig parameters and prefixes from
their attached networks. Hosts use them to reach off-link nodes via default
or more-specific routes. But, a new breed of routers (i.e., "routers") is
emerging from paradigms such as Mobile Ad-hoc Networks. "routers"
typically advertise host routes only (aka, "addresses" or "locators") and
no prefix or autoconfig parameters at all.

I talked about this dichotomy several years ago in my writings
in the MANET wg and in some of the contract work I did at SRI
International. The dichotomy is also discussed in documents such
as the "global6" work by Charles Perkins and his colleagues. But,
the notion of "routers" has really been around for decades and is
quite well known in some circles.

In the MANET paradigm, "routers" often have only a single network
interface which may be used for multi-hop forwarding within a flat
addressing space (i.e., using host routes and redirects to steer the
multi-hop forwarding decisions) while "ROUTERS" are used to reach
other off-link networks. But, the same paradigm can be applied to the
emerging global IPv6 Internet.

In particular, I believe we will soon see an emerging paradigm for
IPv6 in which most (if not all) nodes will be "routers" and a smaller
subset of the nodes will be "ROUTERS". A node can qualify as a
"router" IFF it has the proper credentials so that other nodes can
guard against redirection attacks. The NOID approach specifies
a method by which "routers" may attain the proper credentials
(it also supports site-multihoming as an added attraction):

  http://www.ietf.org/internet-drafts/draft-nordmark-multi6-noid-01.txt

"routers" will also need a means for distributing host routes w/o
including the normal information traditional "ROUTERS" advertise.
The "Default Router Preferences, More-Specific Routers and Load
Sharing" approach specifies the necessary mechanisms:

So, what is missing? It would be desireable for a node sending
an RFC 2461 Router Solicitation to be able to specify whether
"ROUTER" or "router" information (or both) was being solicited.
This function can be accommodated by either providing a codepoint
(i.e., 1-2 bits) in the existing Router Solicitation message or a new
IPv6 Neighbor Discovery message type (call it a "Type II Router
Solicitaiton" for lack of a better name.) Perhaps this isn't even
needed; I would be happy to let others comment.

So, where does the "all nodes are routers" model lead us? To an
IPv6 Internet with end-to-end security, site multihoming, multi-hop
forwarding capability, and a restoration of the end-to-end principles.

I think we need to get on board with this, folks...

Fred
[email-masked]

---

From: Havard Eidnes <[email-masked]>
Date: Tue, 25 Nov 2003 15:28:39 +0100 (CET)

Hm,

I hope I'm not the only one who find the choice of wording to be
unfortunate.

From the 10km-high perspective, there should be other and more
fundamental distinguishing marks than the prefix length of
advertisments or more general protocol behaviour to draw the line
between what has traditionally been named "hosts" and "routers".

I'll therefore give some pushback on introducing a subtle
for-ipv6-only distinction between "ROUTERS" and "routers".

Regards,

- Håvard

---

From: Fred Templin <[email-masked]>
Date: Tue, 25 Nov 2003 07:05:50 -0800 (PST)

Whoops! I got just a tad bit overboard in my message and need to
add some balance. There will still be *plenty* of simple hosts in the
new paradigm that neither need nor want to be considered as "routers"
or "ROUTERS". They will include things like my home printer, my
home security system, my car's speedomeer, etc. These will be
good candidates for an IPv6 local addressing scheme of some sort.
 
Fred Templin
[email-masked]
[email-masked]

Fred Templin <[email-masked]> wrote:
The v6ops discussion from the 'draft-ietf-v6ops-mech-v2-01.txt' thread
took on an interesting twist that I felt warranted a new subject heading.

Fred
[email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 25 Nov 2003 12:07:40 -0500

> 	router is a dangerous idea, and "hybrid router" idea is too.

So, I don't see a particularly good reason to disallow a device from
having distinct router-like and host-like ports, especially if the
strong multihoming model is in effect, so the device doesn't forward
packets to or from the hostlike ports.

(One obvious application for this is out-of-band management networks,
which generally don't seem worth it to me in many cases..)

					- Bill

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 26 Nov 2003 03:33:41 +0900 (JST)

> packets to or from the hostlike ports.

	i think the above is "give people guns to shoot their own foot"
	approach.  i think the stability of router infrastructure is more
	important than permitting "shoot their own foot" config.

	for autoconfiguring novice user's home router (where routers would
	need to be autoconfigured with /48 prefix), we have prefix delegation
	proposal.

itojun

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Wed, 26 Nov 2003 14:12:12 +1100

On 2003-11-25, Fred Templin wrote:
> [...]
> interface which may be used for multi-hop forwarding [...]

Firstly, I don't think differentiating 'router' and 'ROUTER' is
a good idea.  I for one would find it hard to follow in conversation :-)

I think the usual definition of Router is a good one -- a Router
is a node which forwards packets.  

It seems to me that the confusion is not in the definition of
Router, but in the definitions of 'Interface', 'Link' and 'Network',
which don't generally take wireless into account.

-----Nick