Subject: RE: RFC 2529 (6over4)

From: Richard Draves <[email-masked]>
Date: Mon, 9 Aug 1999 20:29:17 -0700

(As an aside, I would really rather not change the source/target link-layer
address option format for 6over4. We have deployed the existing format. And
the current format aligns the IPv4 address, if you care about that.)

About the DF bit and PMTU discovery...

I'm having trouble understanding how PMTU discovery at the IPv4 layer would
usefully interact with 6over4. At least the way our implementation works
(and this is universal I would guess - RFC 2461 specifies a LinkMTU
conceptual variable this way), a node maintains a link MTU that applies to
all neighbors on the link. Suppose IPv4 PMTU discovery gave you different v4
PMTUs for different 6over4 neighbors. Since there's only one link MTU, we
would need to use the minimum of the different PMTUs I suppose.

With implementations like ours, the only way in which the link MTU can be
large is if all 6over4 neighbors are reachable with the large MTU, in which
case the large 6over4 MTU should be configurable with a Router
Advertisement. You don't need v4 PMTU.

Note - it would be useful if section 2 of RFC 2529 specified that the
default MTU of 1480 can be raised to a specified upper-bound as well as
lowered via Router Advertisements. Although there's a little conflict with
RFC 2461 (Neighbor Discovery) section 6.3.4:
   If the MTU option is present, hosts SHOULD copy the option's value
   into LinkMTU so long as the value is greater than or equal to the
   minimum link MTU [IPv6] and does not exceed the default LinkMTU value
   specified in the link type specific document (e.g., [IPv6-ETHER]).
Whereas for 6over4 you want to have a default LinkMTU of 1480, but allow RAs
to specify a larger LinkMTU up to ~64K.

It's a little tricky to have an implementation that would allow a different
link MTU for different neighbors on the link. For example, what MTU would
the sender use for a multicast destination? Just allow fragmentation for
multicast destinations? So I guess I can imagine a 6over4 implementation
that would use v4 PMTU discovery, but it's a stretch.

Rich

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Monday, August 09, 1999 8:49 AM
> To: David Borman
> Cc: [email-masked]; [email-masked]; Richard Draves
> Subject: Re: RFC 2529 (6over4)
> 
> 
> David,
> 
> You're causing me second thoughts about this. Rich Draves, as
> an implementor, do you have a comment?
> 
>    Brian
> 
> David Borman wrote:
> > 
> > > Date: Fri, 06 Aug 1999 17:43:28 -0500
> > > From: Brian E Carpenter <[email-masked]>
> > > Subject: Re: RFC 2529 (6over4)
> > >
> > > Dave, I think the point is that IPv6 will do MTU discovery anyway;
> > > so there is no need to do it at the IPv4 level too.
> > 
> > Not true.  The IPv6 MTU discovery will not learn anything about
> > the section of the path that is traversed as 6over4 packets.  Once
> > the packet is encapsulated, if the DF bit is not set, it will just
> > go on its way, getting fragmented as needed, and reassembled at
> > the other IPv4 side.  To the IPv6 code, it looks like the packet
> > took 1 hop, and did it successfully in one piece.  So, IPv6 can't
> > discover the smaller MTU along the 6over4 path, unless the DF bit
> > is set in the outer IPv4 packet.
> > 
> > 6over4 is really no different than ESP/AH tunnels with respect to
> > Path MTU discovery, the same basic issues are involved in both
> > cases.  See Section 6.1 of RFC 2401.
> > 
> >                 -David Borman, [email-masked]
> 
> -- 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Brian E Carpenter (IAB Chair)
> Program Director, Internet Standards & Technology, IBM Internet Div
> On assignment for IBM at http://www.iCAIR.org 
> Non-IBM email: [email-masked]
> 
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Cyndi Jung <[email-masked]>
Date: Tue, 10 Aug 1999 15:17:25 -0700

A very compelling argument for the DF bit to MUST NOT be set.
Thanks - I feel quite confident about it now.

Cyndi

---

From: Jim Bound <[email-masked]>
Date: Tue, 10 Aug 1999 20:47:29 -0400

Cyndi,

>Thanks - I feel quite confident about it now.

I felt Dave and Sowmini's arguments were more compelling that the above
should be SHOULD NOT.   Rich provided a good sophist argument which
attempts to reduce the need of the DF bit, but does not address the
issue that it could be used and useful for the future.  Hence, all logic
and 23 years of engineering experience and shipping products tells me I
would rather have it be SHOULD NOT in case we have to use it.  I think
we need to be a bit liberal here rather than conservative.

As far as implementations there is only one and I think its just a
research effort?  But if its not I would be glad to be wrong.
I know Francis is working on it now, and would really like to hear
Francis's view on this too?

p.s. Also Sowmini and Dave are engineers working on IPv6 products and in
Dave's case his group has shipped a real IPv6 product.  So that counts
more for me too, if this is just to pare down to philosophy and logic.

/jim

---

From: Cyndi Jung <[email-masked]>
Date: Tue, 10 Aug 1999 18:55:48 -0700

Maybe I read what I wanted to read in what Richard wrote - that the
IPv4 MTU between pairs of neighbors on a 6over4 subnet would not
be a constant value, and in order to ensure that no V6 packet
is dropped because the V4 header had the DF bit set, the routers
would need to determine the minimum V4 MTU between all pairs (information
they might not be able to acquire) or some person would need to manually
configure that number into the router so that it could advertise it to
all the nodes via the RA.  

Sounds like a pain either way - do we have some fundamental distrust of 
V4 fragmentation/reassembly going on here?  It is always available, why not
use it?

Cyndi

---

From: Jim Bound <[email-masked]>
Date: Tue, 10 Aug 1999 22:16:39 -0400

>all the nodes via the RA.  

The packet should not get dropped but an ICMP Packet Too Big should be
generated and 6over4 should deal with it via PMTU discovery. 

>V4 fragmentation/reassembly going on here?  It is always available, why not

Yes of course its bad for ones network health.  See Jeff Mogul paper on
this subject (I don't have a pointer off the top of my head but if you
want to read it I can find it).  Also we disallowed it in IPv6 except
end-to-end routers don't fragment in IPv6.

/jim
Cyndi

---

From: Cyndi Jung <[email-masked]>
Date: Tue, 10 Aug 1999 19:34:24 -0700

>generated and 6over4 should deal with it via PMTU discovery. 

It still sounds painful, when the mechanisms are there to handle it 
in IPv4.

>end-to-end routers don't fragment in IPv6.

I thought it was eliminated in order to simplify the frame format for
streamlined processing, not because it was a Bad Thing.

Surely your nodes MUST implement V4 fragmentation/reassembly?

Also, I think Jeff Mogul wrote that RFC a very long time ago, when things
were really different on the Internet, and people didn't really take the
Internet as seriously as they do today, and the implementations were
truly toys.  It's different now, isn't it?  Aren't NFS frames regularly
fragmented from 8K down to multiple 1K fragments?  Granted, that happens
at the originating node, but they are reassembled just fine.  It really
does work these days.

Cyndi

---

From: Jim Bound <[email-masked]>
Date: Tue, 10 Aug 1999 23:02:43 -0400

It seems to me life would be better for routers if they did not have to
fragment and I think a benefit to them with IPv6.

As far as originating nodes doing the frag thats fine most think I guess
and we permit it in Ipv6.

Did not mean to get us on this thread.    

/jim

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 11 Aug 1999 08:58:59 -0500

> be a constant value,  ...

That's what I read, and to me it spelled "case closed".  All of the
IPv4 network that appears as one link to 6over4 would have to have a
uniform MTU for IPv4 PMTUD to be useful.  One wiseacre anywhere and
bang, you're sending 68 byte packets to everyone.

				Matt

---

From: Francis Dupont <[email-masked]>
Date: Wed, 11 Aug 1999 18:52:29 +0200

In your previous mail you wrote:

=> I believe David has a very good argument then "SHOULD NOT"
is enough (but this doesn't change for me, I had bad experiences
with IPv4 PMTU then I almost always clear the DF bit and experiment
PMTU discovery on tunnels only with IPv6 over IPv6 :-).
 I don't know if in the case of multicasts something specific should be
specified, usually it is a *bad* idea to fragment IPv4 multicasts
(no PMTU discovery) but it should work...

Regards

[email-masked]

PS: about link-layer addresses, there are *not* useful for IPv6 over IPv4
point-to-point tunnels. When a Cisco sends a link-layer info in RA, it
should be checked and dropped!
I think 6over4 is the only IPv6 over IPv4 object where link-layer infos
are really used.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 19 Aug 1999 15:09:51 -0700 (PDT)

> that would use v4 PMTU discovery, but it's a stretch.

While we haven't built 6over4 yet (shame on us :-)
we have the infrastructure in place for having the IPv6 pmtu be affected by
the IPv4 pmtu when tunneling over IPv4. This is used to make configured and
automatic tunnels work as specified in RFC 1933.

But when we do 6over4 IPv4 multicast packets need to pick one fixed MTU value
and the DF big can not be set on them (since multicast packets with DF
set are silently dropped - no ICMPv4 errors are allowed in response to
multicast packets - something that ICMPv6 changed).

   Erik