Subject: [v4v6interim] Fragmentation Options in NAT6 presentation

From: Hiroshi MIYATA <[email-masked]>
Date: Fri, 3 Oct 2008 18:31:04 +0900

Jennings,

FYI.
Though it is already clearly explained by Dave, let me give you the
pointer.
The answer for your question of "Fragmentation options" is clearly
stated in RFC2765(SIIT) as end-to-end path MTU discovery.
See Section 3 and 4.

And of course RFC1981(PMTUD) is compliant with it. ;-)
Chap. 4
       Note: A node may receive a Packet Too Big message reporting a
       next-hop MTU that is less than the IPv6 minimum link MTU.  In  
that
       case, the node is not required to reduce the size of subsequent
       packets sent on the path to less than the IPv6 minimun link MTU,
       but rather must include a Fragment header in those packets [IPv6-
       SPEC].

It must work well. ;-)

Regards,

....miyata
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Fri, 3 Oct 2008 14:36:00 -0400

Some SP's may view ICMP as an attack vector and may explicitly block
ICMP messages.

In this case, the only way to get connectivity for packets that are too
large is to fragment.

- Wes 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Hiroshi MIYATA
Sent: Friday, October 03, 2008 5:31 AM
To: [email-masked]
Subject: [v4v6interim] Fragmentation Options in NAT6 presentation

Jennings,

FYI.

And of course RFC1981(PMTUD) is compliant with it. ;-) Chap. 4

It must work well. ;-)

Regards,

....miyata

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 3 Oct 2008 21:16:34 +0200

Or more precisely, SP won't block ICMP in transit but have NO choice but rate limiting the number of ICMPv6 packet too big _generated_ by a router to 100 pps or so... (NB: this is already the case now in IPv4 and IPv6 in order to save CPU)

Of course, if Google Map (or any other applications) has to open 50+ connections per end-user transaction, and if there are more than 2 end-users connecting to Google Maps within the same second (this is assumed to by ironical -- Friday evening), then some connections will fail... (cached information will only be available after the connection timed out I'm afraid).

Hence the importance of setting 'manually' the MTU right at the edge where the ICMP generation rate is probably (?) lower than in the core.

-éric

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Wes Beebee 
> (wbeebee)
> Sent: vendredi 3 octobre 2008 20:36
> To: Hiroshi MIYATA; [email-masked]
> Subject: Re: [v4v6interim] Fragmentation Options in NAT6 presentation
> 
> Some SP's may view ICMP as an attack vector and may 
> explicitly block ICMP messages.
> 
> In this case, the only way to get connectivity for packets 
> that are too large is to fragment.
> 
> - Wes 
> 
> Though it is already clearly explained by Dave, let me give 
> you the pointer.
> The answer for your question of "Fragmentation options" is 
> clearly stated in RFC2765(SIIT) as end-to-end path MTU discovery.
> See Section 3 and 4.
> 
>        next-hop MTU that is less than the IPv6 minimum link 
> MTU.  In that

---

From: Hiroshi MIYATA <[email-masked]>
Date: Sat, 4 Oct 2008 04:51:28 +0900

Correct!

We have met the problem, and, yes, only the way is fragmenting
the packet on the Translator.
We have developed it as a optional behavior.

It may cause the argument if we state it in document, since
it break the PMTU Discovery semantics.

But it is the fact.

Maybe it is not recommended to describe on BEHAVE documents
as a requirement.
But we should give the hint of this issue on the documents
as possible problems and solution and utilization (since
it is not recommended to use this in public service, but
possible to be used for controllable area of the administrator.)

Regards,

....miyata

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 04 Oct 2008 12:46:05 +1300

Actually the *correct* solution is to use a method of
PMTU discovery that does not depend on ICMP.
That's the point of RFC 4821.

  Brian

---

From: Hiroshi MIYATA <[email-masked]>
Date: Sat, 4 Oct 2008 17:56:35 +0900

Brian,

Thanks for your input.
I will investigate it!

Cheers!

...miyata

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Mon, 6 Oct 2008 12:34:51 -0400

I do agree that RFC 4821 is the right solution, and should be used in
recommendations in IETF documents.

However, how many stacks actually implement RFC 4821?

Perhaps by merely publicizing more widely its existence, we might be
able to lure more implementors... 

- Wes

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Friday, October 03, 2008 7:46 PM
To: Hiroshi MIYATA
Cc: Wes Beebee (wbeebee); [email-masked]
Subject: Re: [v4v6interim] Fragmentation Options in NAT6 presentation

Actually the *correct* solution is to use a method of PMTU discovery
that does not depend on ICMP.
That's the point of RFC 4821.

  Brian

On 2008-10-04 08:51, Hiroshi MIYATA wrote:
> Correct!
> 
> We have met the problem, and, yes, only the way is fragmenting the 
> packet on the Translator.
> It may cause the argument if we state it in document, since it break 
> the PMTU Discovery semantics.
> 
> But it is the fact.
> 
> Maybe it is not recommended to describe on BEHAVE documents as a 
> requirement.
> But we should give the hint of this issue on the documents as possible

> problems and solution and utilization (since it is not recommended to 
> use this in public service, but possible to be used for controllable 
> area of the administrator.)
> 
> Regards,
> 
> ....miyata
> 
> 
>> In this case, the only way to get connectivity for packets that are 
>> too large is to fragment.
>>
>> - Wes
>>
>> [mailto:[email-masked]]

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 6 Oct 2008 22:19:18 +0200

Am I the only finding weird to assume that servers (and clients depending on the application) would be upgraded to support PLPMTUd while still being unable to do dual-stack?

Assuming that a server is 'important' enough to get a PLPMTUd software upgrade, then we could assume as well that it can get both an IPv4 and an IPv6 addresses, couldn't we? 

Or am I missing something? (which is quite possible of course)

-éric

> Actually the *correct* solution is to use a method of PMTU 
> discovery that does not depend on ICMP.
> as possible
> MTU.  In

---

From: Fred Baker <[email-masked]>
Date: Mon, 6 Oct 2008 17:28:36 -0700

On Oct 6, 2008, at 1:19 PM, Eric Vyncke (evyncke) wrote:

> Am I the only finding weird to assume that servers (and clients  
> depending on the application) would be upgraded to support PLPMTUd  
> while still being unable to do dual-stack?

I'm not sure that's an accurate statement. End system implementations  
(Mac, Linux, BSD, Solaris, Windows Vista and some earlier versions)  
generally are dual-stack-capable these days. The issue is that the  
network connecting them isn't.

That's the premise in DS-Lite; that one could use the network as  
bandwidth, eliminate all network-based services, and simply tunnel  
through it to build a next generation overlay. ISPs that think they  
are offering services besides bandwidth might eventually decide they  
don't want to be tunneled over, smell the coffee, and change.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Tue, 7 Oct 2008 10:47:56 +0300

> However, how many stacks actually implement RFC 4821?

There are really two separate categories:

For TCP (and SCTP), this needs to be supported by the IP stack. The widespread 
use of TCP MSS clamping makes it obvious that many if not most IP stacks do 
not support this as yet.

For UDP, this needs to be implemented directly into the application-layer, 
with some additional support from the IP stack (to allow sending too large 
packets with DF bit). As yet, Linux is the only IP stack that explicitly 
supports this via some "proprietary" socket API options. As for applications, 
it is difficult to gather meaningful data. But considering the lack of 
support from lower layers, it is likely that this is mostly not implemented. 
I empirically believe that most applications simply have a "safe" hard-coded 
MTU for UDP, e.g. 1400 bytes or whatever.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Oct 2008 10:00:56 +1300

> MTU for UDP, e.g. 1400 bytes or whatever.

In any case, I assume we have to wait at least 5 years before the RFC4821
approach is widely deployed. But since the problem of MTU size and
ICMP blocking is widespread, I think we should recognise that it isn't
specific to the NAT6[4] scenarios, and that the solution needs to be general.

   Brian

---

From: Mark Andrews <[email-masked]>
Date: Wed, 08 Oct 2008 10:14:08 +1100

In message <[email-masked]>, "=?iso-8859-1?q?
R=E9mi?= Denis-Courmont" writes:
> For TCP (and SCTP), this needs to be supported by the IP stack. The widespr=
> ead =
> 
> use of TCP MSS clamping makes it obvious that many if not most IP stacks do =
> 
> not support this as yet.
> 
> For UDP, this needs to be implemented directly into the application-layer, =
> 
> with some additional support from the IP stack (to allow sending too large =
> 
> packets with DF bit). As yet, Linux is the only IP stack that explicitly =
> 
> supports this via some "proprietary" socket API options. As for application=
> s, =
> 
> it is difficult to gather meaningful data. But considering the lack of =
> 
> support from lower layers, it is likely that this is mostly not implemented=
> . =
> 
> I empirically believe that most applications simply have a "safe" hard-code=
> d =
> 

	Any IP stack which sets DF for UDP without the application
	requesting it is broken.

	If you do want to be able to set DF for UDP you also need
	to have a way to tell the IP stack to fragment the UDP
	packet into fragements no larger than a certain size.
 
	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 7 Oct 2008 16:24:38 -0700

...
> 	packet into fragements no larger than a certain size.

A procedure to perform UDP Path MTU Discovery is described in
http://tools.ietf.org/html/draft-petithuguenin-behave-stun-pmtud and uses the
'modern' RFC4821 technique (rather than RFC1191's technique that relies on
ICMP).  However, so far the BEHAVE working group has received few comments on
that draft.  I can only interpret the few comments to mean there is no
interest in the technique -- which frankly surprises me.  If it's interesting
or useful or it can be improved, please email the author ([email-masked],
CC'd on this message) or [email-masked].  Thanks!

-d

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 09 Oct 2008 14:43:31 +0200

> MTU for UDP, e.g. 1400 bytes or whatever.

You can't make 4821 style PMTUD generic over UDP. The issue is of course
the feedback that needs to be integrated with the protocol. And that you
need to have some way of knowing exactly which packet is which.

When it comes to "safe", no value is truly safe and that is the issue.
Things starting to get really high success rates when you go down below
500 bytes, i.e. 576 - reasonable overhead. But even 1400 is to big in a
number of places for IPv4 networks. Also the tendency to make tunnels in
tunnels is one of the bigger issues about how much you should deduct.

Thus in addition to get TCP and SCTP stacks to implement 4821, have
application that uses other transport to also include solution we do
need a solution for the address family translation that support
fragmentation enabled to avoid black holes.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Oct 2008 09:23:57 +1300

...
> number of places for IPv4 networks. 

Yes, I'm just fighting a link a few hops from me that seems to have
an MTU of 1232, which transitions IPv6 into a big black hole...

   Brian

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 10 Oct 2008 09:59:01 +0300

> need to have some way of knowing exactly which packet is which.

I agree. I actually believe that this is one half one the problem: there is no 
(semi-)standard way to do this with the a UDP BSDish socket.

To the best of my knowledge, Linux supports this through IP_MTU_DISCOVER, in a 
awkward yet usable way. On Windows, you can set the DF bit, but that's about 
it. On BSD/OSX, you cannot even set the DF bit. I might be wrong.

> tunnels is one of the bigger issues about how much you should deduct.

Sure. In fact, my 3G provider sets an MTU of 1400 bytes, so sending UDP 
packets with 1400 bytes payload would be awfully bad.

> fragmentation enabled to avoid black holes.

In Dublin, I thought we came to the conclusion that all significant IPv6 
stacks supported the provision for fragmentating IPv6 even below 1280 bytes. 
If I understand correctly, they then send IPv6 packets with a fragment 
header, so that it is "easy" for the translation box to do its job.

As for IPv4 side, I think we have what we have and we cannot improve it much. 
If the application supports 4821, good. If not, then well, it might not work, 
with and without IPv6 translation. However, I think it would be (or have 
been) a good idea to promote an Informational socket API extension for 
RFC4821, so that apps can control the DF bit, fetch the known MTU, dequeue 
per-destination Too Big errors, etc.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 14 Oct 2008 11:05:39 +0200

On 3 okt 2008, at 21:16, Eric Vyncke (evyncke) wrote:

> Or more precisely, SP won't block ICMP in transit but have NO choice  
> but rate limiting the number of ICMPv6 packet too big _generated_ by  
> a router to 100 pps or so... (NB: this is already the case now in  
> IPv4 and IPv6 in order to save CPU)

Right.

> Of course, if Google Map (or any other applications) has to open 50+  
> connections per end-user transaction

Which it doesn't. In fact, when I try it I only see a single  
connection, but a bunch of stuff may be cached. AFAIK, a browser only  
sets up two sessions to the same FQDN. When there are lots of sessions  
this happens when lots of elements (ads...) need to be loaded from  
different FQDNs.

Also note that Google uses packets smaller than 1500 bytes.

> and if there are more than 2 end-users connecting to Google Maps  
> within the same second (this is assumed to by ironical -- Friday  
> evening), then some connections will fail...

Only if 100 sessions all send a large packet within a roundrip from  
the server to the router. Since the client needs to load a bunch of  
stuff before the additional sessions can be started this won't happen.

But I guess it could with 100+ different users at the same time.

> (cached information will only be available after the connection  
> timed out I'm afraid).

What do you mean timed out?

> Hence the importance of setting 'manually' the MTU right at the edge  
> where the ICMP generation rate is probably (?) lower than in the core.

You mean using large MTUs in the middle. Then you don't have trouble.  
Using small MTUs in the middle isn't a good idea.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 14 Oct 2008 11:16:11 +0200

> Using small MTUs in the middle isn't a good idea.

Actually, I mean two things (which have the same cause & effect):
- try to avoid small MTU in the core
- generate ICMP at the edge
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim