Subject: Evolution of the IP model - ICMP and MTUs

From: Rémi Després <[email-masked]>
Date: Fri, 15 Aug 2008 08:40:26 +0200

Dave,

I find your work on the IP model quite interesting.
To answer your invitation to send comments, one remark.

It concerns Path Maximum Transmission Unit Discovery (PMTUD), and more
precisely its relationship to ICMP and Fragmentation.

- In the original model, senders of datagrams with the DF bit set (Don't
Fragment) received  no information back, when these packets were
discarded on their way because of their being "too big", about what size
would have fit.
- In 1990, the Next-Hop MTU information was added to Datagram Too Big
ICMP message (RFC 1191).
- Thus, hosts have a chance to quickly discover exact path MTUs. (They
have only "a chance" because: (1) ICMP messages, like any other packets,
are returned in best effort mode; (2) some routers may have not
implemented Next-Hop MTUs; (3) some firewalls filter ICMP packets.)
- The upper layer TCPs can now take advantage of this IP-layer provided
information to adjust their  Maximum Segment Size MSS (sec. 3.1 of RFC
1191).

IMHO, this evolution would be worth noting in a next version of your draft.

Regards,

Rémi

---

From: Christian Huitema <[email-masked]>
Date: Fri, 15 Aug 2008 13:14:10 -0700

If you want to document the evolution, you have to be complete.

1) In the original model, senders of datagrams with the DF bit set
 (Don't Fragment) received  no information back.
2) In 1990, the Next-Hop MTU information was added to Datagram Too Big
 ICMP message (RFC 1191).
        Hosts have a chance to discover the real MTU in the path using ICMP
3) Around 1995, firewalls started to drop all ICMP by default
        Hosts that rely on ICMP to discover PMTU observe terrible performance
4) Around 2000, broadband connections start being equipped with tiny "home
   routers" whose NAT function does a pretty bad job at reassembling IP packets
        Hosts that send packets too large observe terrible performance, and they
        are in a bind since PMTU discovery does not work well.
5) By 2008, the IETF might recognize that firewalls are here to stay,
   that we could just as well forget about ICMP, but that we really
   need another solution.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Rémi Després
> Sent: Thursday, August 14, 2008 11:40 PM
> To: Dave Thaler; v6ops
> Subject: Evolution of the IP model - ICMP and MTUs
>
> Dave,
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Aug 2008 13:53:10 -0700

1.5) In 1987, "Fragmentation Considered Harmful".

Fred 

>From: Christian Huitema [mailto:[email-masked]] 
>Sent: Friday, August 15, 2008 1:14 PM
>To: Rémi Després; Dave Thaler; v6ops
>Subject: RE: Evolution of the IP model - ICMP and MTUs
>

---

From: Rémi Després <[email-masked]>
Date: Sat, 16 Aug 2008 18:58:47 +0200

>    that we could just as well forget about ICMP, but that we really

- Well, I don't "want" anything here. Just trying to answer Dave's 
invitation to comment.
- Please note that I did mention that "some firewalls filter ICMP packets".
- IMU, your more detailed comments are worth being included too (except 
5., wich is a comment about the future).
- In particular a brief summary of what you mean by "a pretty bad job at 
reassembling packets" should IMO have its place in Dave's document, its 
scope being the evolution of the IP model.

Regards,

Rémi Després

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 16 Aug 2008 11:55:13 -0700

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Rémi Després
> Sent: Saturday, August 16, 2008 9:59 AM
> To: Christian Huitema
> Cc: Dave Thaler; v6ops
> Subject: Re: Evolution of the IP model - ICMP and MTUs
> 

A NAPT -- like a host -- has a limited amount of resources it
wants to dedicate to reassembling fragments.  But a NAPT is
in front of many hosts (and thus sees more fragments than
any one host).  To perform its NAPT function, the NAPT needs 
to see the first fragment (containing port numbers); if the
packets arrive out of order, the NAPT needs to (a) discard
the fragments [causing the entire packet to be lost] or 
(b) store the fragments until the first fragment arrives or
until a timer expires.

See also RFC 4963, "IPv4 Reassembly Errors at High Data Rates"
(used to be titled "Fragmentation Considered Very Harmful").

-d

---

From: Rémi Després <[email-masked]>
Date: Mon, 18 Aug 2008 08:45:30 +0200

1.
Thanks Dan for the ref. to RFC 4963. I had not noticed this RFC, 
important as far as the evolution of the IPv4 model is concerned.

IMU, since it shows that, at high data rates, IPv4 fragmentation can 
lead to undetected data corruption at the IP layer, it implies that 
fragmentation SHOULD be discarded from an updated IPv4 service model 
(the DF bit MUST be set in all packets).

Applications that can send datagrams longer than typical MTUs (AFAIK, 
Sun NFS needs 8 K) can still work in strict conformity with the IP 
model, but in IPv6.

2.
With no fragmentation in the IPv4 model, packet losses due to
insufficient reassembly resources are no longer a concern.

3.
Where ICMP is not filtered by FWs, upper layers can take advantage of
MTU information which, since RFC 1191 of 1990, may be returned in Packet 
too Big ICMP massages.

Rémi Després

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 17 Aug 2008 23:58:05 -0700

I don't recall if RFC4821 was included in your earlier list.  RFC4821
describes how to do Path MTU Discovery without ICMP.  

As you know, doing PMTUD over UDP requires each application to do it
themselves.  Marc Petit-Huguenin describes how to do RFC4821-style (that is,
ICMP-less) PMTUD for UDP in draft-petithuguenin-behave-stun-pmtud-01, provided
the application can demultiplex STUN messages from its normal application
payloads (the STUN magic-cookie and the STUN fingerprint can be used to demux,
which makes demuxing easier).

-d

> From: Rémi Després [mailto:[email-masked]] 
> Sent: Sunday, August 17, 2008 11:46 PM
> To: 'Dave Thaler'; Dan Wing
> Cc: 'v6ops'

---

From: Rémi Després <[email-masked]>
Date: Mon, 18 Aug 2008 10:10:03 +0200

Christian Huitema  - Le 8/15/08 10:14 PM :
> By 2008, the IETF might recognize that firewalls are here to stay, 
> that we could just as well forget about ICMP, but that we really need
> another solution.

1.
- I agree with you that Firewalls are here to stay (and not only in 
hosts themselves where they are more and more an absolute must).
- To avoid too much parasite traffic on radio links, there seems to be 
no altarnative to FWs in ISP infrastructures.

2.
On the other hand, forgetting about ICMP altogether would be a 
revolution  which, IMHO and with available information, would make no 
sense. (But if you have more material on the subject, it's of course 
worth looking at.)

3.
- How ICMP error messages coming from external realms MUST be treated in 
NATs is well proposed in section 4.2.1 of 
http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-icmp-08.txt.
- IMHO, firewalls have no reason to act differently.

Regards.

Rémi Després

---

From: Rémi Després <[email-masked]>
Date: Mon, 18 Aug 2008 10:57:40 +0200

Dan,

Thanks for the RFC4821 and M Petit-Huguenin's I-D references. I knew and 
their predecessors but had not read these two.

The value of PMTUD mechanisms that work even when ICMP error messages 
are missing is clear.

Yet, since convergence to the right PMTU can be much faster if ICMP 
error messages are forwarded and processed, it seems useful to have this 
fact well understood, and advertised.

NAT and FW providers have IMO to keep (or restore) their motivation to 
forward ICMP error messages on established connections.

Rémi Després

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 18 Aug 2008 11:12:05 +0200

> (Don't Fragment) received  no information back.

"Fragmentation needed and DF set" is defined in RFC 792, predating  
path MTU discovery by the better part of a decade.

>        are in a bind since PMTU discovery does not work well.

All the home NAT boxes I've used can handle common ICMP messages just  
fine as traceroute works through them.

>   that we could just as well forget about ICMP, but that we really

Considering you work for Microsoft, I'm interested to learn what you  
guys plan to do about this.

In May there was a discussion on NANOG in May about the fact that the  
*.microsoft.com servers send packets with DF set, but ignore incoming  
ICMP too big messages. Now obviously that combination of actions  
doesn't work.

So are you going to abolish PMTUD and send packets with DF=0 and IPv6  
packets that are no larger than 1280 bytes? (If you make a Windows XP  
box an IPv6 router it will create PMTUD black holes because it filters  
incoming too bigs.)

Or maybe you're going to implement RFC 4821? But then what about  
correspondents that don't implement this (yet)? And what about  
transport protocols that are incompatible with RFC 4821 because they  
can't change their message size easily?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 18 Aug 2008 11:17:54 +0200

On 18 aug 2008, at 8:45, Rémi Després wrote:

> IMU,

IMU?

> since it shows that, at high data rates, IPv4 fragmentation can lead  
> to undetected data corruption at the IP layer, it implies that  

What about actually FIXING the problem.

I remember that when I first read about IPv6 (many a moon ago) I  
noticed that IP packets had an unfragmentable and fragmentable parts.  
So I thought "excellent, they got it right, the port numbers are now  
in all fragments!" Unfortunately, that wasn't the case.

However, we could come up with a new fragment header for both IPv6 and  
IPv4 that DOES have all the information NATs and firewalls need in the  
fragment header, as well as a larger ID field. This would of course  
take significant time to get deployed, but considering that we've been  
limping along with broken PTMUD for a decade and a half having a GOOD  
solution may be worth the wait.

---

From: Rémi Després <[email-masked]>
Date: Mon, 18 Aug 2008 11:46:01 +0200

Iljitsch van Beijnum  - Le 8/18/08 11:17 AM :
> I remember that when I first read about IPv6 (many a moon ago) I noticed 
> that IP packets had an unfragmentable and fragmentable parts. So I 
> thought "excellent, they got it right, the port numbers are now in all 
> fragments!" Unfortunately, that wasn't the case.
> 
> fragment header, as well as a larger ID field. This would of course take 
> significant time to get deployed, but considering that we've been 

Fixing the problem for IPv6 may be worth the pain, but fixing it for 
IPv4 (the only subject of my comment) would IMO be counterproductive.

Do you know applications other than NFS on UDP that, needing to transmit 
longer than than 1280 octet datagrams, impose fragmentation even in IPv6?

If there is none, the "fixing" could be:
- Always use NFS on TCP.
- In IPv6, firewalls that cannot perform their function properly on 
fragmented datagrams impose a 1280 octet MTU (and return ICMP error 
messages when discarding fragmented datagrams).

RD

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 18 Aug 2008 14:21:16 +0200

On Mon, 18 Aug 2008 11:17:54 +0200, Iljitsch van Beijnum

> IMU?

In My Understanding, I guess.

> solution may be worth the wait.

And would cause the packet to be rejected by existing middleboxes. Hmm...

Firewalls can simply let every non first fragments in. Deep packet

inspection needs to de-fragment anyway - adding the port number to every

fragment does not help. Hence, this issue is really only about NATs.

Anyway, too late for IPv4. With IPv6, it supposedly has no NATs, and even

if it had, it seems that it could be a pure network ADDRESS translator

rather than a network ADDRESS and PORT translator. In that case,

fragmentation is a non-issue.

-- 

Rémi Denis-Courmont

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 18 Aug 2008 14:37:03 +0200

On 18 aug 2008, at 11:46, Rémi Després wrote:

>> However, we could come up with a new fragment header for both IPv6  
>> and IPv4 that DOES have all the information NATs and firewalls need  
>> in the fragment header, as well as a larger ID field.

> IPv4 (the only subject of my comment) would IMO be counterproductive.

Counterproductive?

> Do you know applications other than NFS on UDP that, needing to  
> transmit longer than than 1280 octet datagrams, impose fragmentation  
> even in IPv6?

Most applications have more than 1200 bytes of data to transmit, so  
potentially this could be most UDP applications, as well as ALL  
tunneling mechanisms. Now of course applications try to avoid this  
issue by sending smaller packets, but that's a terrible solution,  
because we'll never be able to use bigger packets when our link  
technologies improve.

On 18 aug 2008, at 14:21, Rémi Denis-Courmont wrote:

> And would cause the packet to be rejected by existing middleboxes.

Yes, so deployment would be slow because we need to wait for these to  
be updated or replaced, and the solution would incur some additional  
complexity for deciding whether to use old style or new style  
fragmentation.

> fragment does not help. Hence, this issue is really only about NATs.

Don't forget that this also buys us a larger ID space for IPv4, which  
makes some of the less visible issues with fragmentation go away.

And, if we can solve PMTUD for datagrams (i.e., UDP) life gets a lot  
easier for applications.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 18 Aug 2008 07:30:15 -0700

>(the DF bit MUST be set in all packets).

IMHO, this is taking too narrow a view. The case to be
avoided is *sustained* fragmentation at high data rates.
A little bit of fragmentation is OK as long as it can be
detected and tuned out asap. In some instances, that may
mean setting DF=0.

Fred
[email-masked]

---

From: Rémi Després <[email-masked]>
Date: Mon, 18 Aug 2008 17:03:30 +0200

>> IPv4 (the only subject of my comment) would IMO be counterproductive.
In my Webster dictionary - 10th edition: "tending to hinder the 
attainment of a desired goal", the goal being here sucessful IPv6 
deployment ;-).

> tunneling mechanisms.

I still wonder what are these applications that, having their preferred 
datagram sizes exceeding that of Ethernet frame, don't work properly where:
- Path MTUs are smaller than this size.
- Reassembly in destination NATs generates losses.

Any information on this would be appreciated.

> Now of course applications try to avoid this issue 
> by sending smaller packets, but that's a terrible solution, because 
> we'll never be able to use bigger packets when our link technologies 
> improve.

This solution is in my understanding quite realistic:
- It doesn't prohibits using large packets on large MTU links. (Your 
fear is unjustified).
- Path MTU Discovery algorithms are designed to detect paths that 
support large packets.

RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 18 Aug 2008 17:22:17 +0200

> detected and tuned out asap. In some instances, that may

Yes, you are right.
(As a matter of fact, I had first written that it implied "in practice". 
  It would have been better kept that way).

I have doubts however that the logic to manage that "little bit of 
fargmentation" would be worth it.

Taking the risk that corrupted data would be received, if this logic 
happens to be ill tuned when data rates have continued to increase, 
should IMHO not be recommended.

Recommending a simple and robust logic would be preferable.

RD

---

From: Fernando Gont <[email-masked]>
Date: Mon, 18 Aug 2008 12:29:07 -0300

At 12:03 p.m. 18/08/2008, Rémi Després wrote:

>>>Fixing the problem for IPv6 may be worth the 
>>>pain, but fixing it for IPv4 (the only subject 
>>>of my comment) would IMO be counterproductive.
>>Counterproductive?
>In my Webster dictionary - 10th edition: 
>"tending to hinder the attainment of a desired 
>goal", the goal being here sucessful IPv6 deployment ;-).

So you basically argue that keeping problems in 
IPv4 (on which the current infrastructure depends) would be a driver for v6?

Wouldn't be a better goal to have some many 
interesting features in v6 that nobody could resist deploying it?

(I must admit it is not the first time that I 
hear this type of argument, though... )

Kind regards,

--
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Rémi Després <[email-masked]>
Date: Mon, 18 Aug 2008 18:03:00 +0200

Fernando Gont  - Le 8/18/08 5:29 PM :
>>>> Fixing the problem for IPv6 may be worth the pain, but fixing
>>>> it for IPv4 (the only subject of my comment) would IMO be
>>>> counterproductive.
>>> Counterproductive?
> Wouldn't be a better goal to have some many interesting features in
> v6 that nobody could resist deploying it?> So you basically argue
> that keeping problems in IPv4 (on which the current infrastructure
> depends) would be a driver for v6?
> 
Please note that I argue only for the particular problem at hand, not 
for all "problems".

As Iljitsch put it, what he calls a fix would involve "a new fragment 
header" (not defined overnight, I suppose, especially if it has to be 
applicable to both IPv4 and IPv6). And it "would of course take 
significant time to get deployed".

The point is then that energy would be better spent fixing IPv6 
deployment problems (there remains a few, on which I personally try to 
be active), rather than spent complexifying IPv4 even more.

I haven't the view otherwise that making life purposedly difficult with
one solution in order to promote another one is a right approach.

Thanks for the opportunity to clarify it.

RD

> 
> (I must admit it is not the first time that I hear this type of 
> argument, though... )
> 
> Kind regards,
> 
> -- Fernando Gont e-mail: [email-masked] || [email-masked] PGP
> Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 18 Aug 2008 09:31:46 -0700

>Sent: Monday, August 18, 2008 9:03 AM
>To: Fernando Gont
>Cc: Iljitsch van Beijnum; v6ops Operations

IMHO, making certain aspects of IPv4 better would encourage
bringing IPv6 forward in the right way; not discourage from
bringing IPv6 forward in any way.

Fred

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 19 Aug 2008 13:24:12 +0200

Ok, this is what the new fragment header would look like:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| next header   |res|type |S/F|T|      fragment offset    |res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        identification                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          source port          |      destination port         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    observed packet length     |            checksum           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

next header: protocol number of the header following the new fragment  
header

res: reserved

S/F: SYN/FIN, copied/synthesized from transport

T: 1 = addresses were translated

fragment offset: as usual

type: tcp/udp/sctp/dccp/AH/ESP/other+ports/other-ports

M: more fragments

identification: groups fragments of the same packet, copied from TCP  
sequence if applicable

ports: copied from transport port numbers or IPsec SA

observed packet length: maximum packet size seen in the opposite  
direction in the last 5 minutes, 0 = unknown / no packets larger than  
1280 bytes seen

checksum: checksum of the IP pseudo header + transport segment bytes  
upto byte 1280 of the packet, 0 = N/A

The new fragment header is always the first header following the IPv4  
or IPv6 header. This means that filtering on protocol and port numbers  
is always easy because the information is always present in the same  
place in the packet, even if additional headers are present between  
the new fragment header and the transport header.

When routers observe a packet with the new fragment header that is too  
large to be forwarded, they truncate the packet. The minimum size of  
the first fragment is 1280 bytes. Note that traditional IPv4  
fragmentation produces the same result as truncation for the first  
fragment.

Because the new fragment header has its own checksum over the relevant  
part of the first 1280 bytes of the packet, bit errors can still be  
detected so protocols that can make use of the truncated data (such as  
TCP or DNS) may do so.

NATs MAY only translate the new fragment header.

The observed packet length field allows for passive PMTUD. A full  
PMTUD implementation can be done by initializing the PMTU to 1280 and  
then use a new fragment header for packets larger than the PMTU and/or  
in response to incoming packets that updated the OPL, updating the  
PMTU from the OPL field in incoming packets, resetting the PMTU after  
a retransmission timeout.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 19 Aug 2008 10:32:21 -0400

Disclaimers:

    * I am newly dedicated to working with IPv6, and recently got my /48
      allocation to my home lab.
    * I am currently only working with Centos (v5.2) systems.
    * My 1st main goal is to have P2PSIP (and SIP) running over HIP over
      IPv6. And where IPv6 is not available to use Teredo.

There are probably more I should list up there, but it will do for 
starters. I am using the HIPL code in userspace, as the BEET IPsec patch 
is not yet in the Centos kernel (BEET is in, but it needs the patch to 
work right).

So I need IPv6 apps, and have been having a terrible time of it. I can 
list where I am so far, if there is interest (or help available!), but I 
do not have a single IPv6 client/server app running yet after two weeks 
of work.

Friday, I decided that IPv4 was just getting in my way to find working 
IPv6 apps (until I need to test in a Teredo environment), so I tried to 
disable IPv4. Looks like I cannot, even when I do not start the network 
service, the loopback device is available with both IPv4 and IPv6 
loopback addresses (even when I commented out all references that I can 
find for the IPv4 loopback address).

I find this unsettling. Kind of like an IPv4 forevermore position, with 
IPv6 kind of sometime.....

Just venting some steam, and now back to testing.

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 19 Aug 2008 17:14:56 +0200

Robert Moskowitz wrote:

[Why are you actually sending this to the IETF Operations list and not 
to either the CentOS support lists or other Linux-specific lists which 
most likely can actually resolve your problem? [email-masked] also comes 
to mind here]

> do not have a single IPv6 client/server app running yet after two weeks 

Then I would suggest that you get a distribution that actually supports 
IPv6 correctly. Debian (unstable) is doing this already for years.
For that matter, a simple combination of Apache2 + Firefox should work 
on any platform you can find.

CentOS should also though. Also don't expect anything 
experimental/fairly new (HIPL etc) to just be included in a distribution 
per default.

> disable IPv4.

Why would one, today, want to disable IPv4? Unless you are going to 
proxy every single application (SOCKS comes to mind to solve that), it 
will not work. See also the threads on 4to6 and other proposals from the 
last couple of months on this and other related lists (RRG for instance).

 > Looks like I cannot, even when I do not start the network

A lot of applications only work on IPv4 and IPC on a lot of Operating 
Systems use the loopback interface for communication, you thus won't be 
able to turn that off easily for the next couple of years.

> IPv6 kind of sometime.....

The IETF's position has for a long time been to suggest dual-stack 
deployment.

Greets,
  Jeroen

---

From: Chuck Anderson <[email-masked]>
Date: Tue, 19 Aug 2008 11:43:05 -0400

> do not have a single IPv6 client/server app running yet after two weeks  

RHEL 5 (and hence Centos 5) was based upon work done in Fedora Core 6.  
Since then, lots of work has been done in Fedora to make sure the OS 
and applications work better on IPv6.  You might want to try running 
Fedora 9 to see if IPv6 works better there.  Here is a tracker for 
IPv6 related bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=195271

Specifically, there is a bug in RHEL 5 that I'm not sure has been 
fixed yet where the default route doesn't work:

https://bugzilla.redhat.com/show_bug.cgi?id=243526

I've been using IPv6 on Fedora for a couple years now, and most stuff 
works fine (web browsing, FTP, IRC, SSH).  Granted, I haven't tried 
some of the more exotic applications like SIP or HIP.

---

From: "Chip Popoviciu (cpopovic)" <[email-masked]>
Date: Tue, 19 Aug 2008 12:17:00 -0400

Then might as well, put a fragment header on all packets so that routers
do not have to cross EH for upper layer info and also make things work
with ESP as well.

Regarding the position of the header, are you saying this header will be
ahead of HbH?

Chip 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Iljitsch van Beijnum
Sent: Tuesday, August 19, 2008 7:24 AM
To: v6ops Operations
Subject: New fragment header, was: Re: Evolution of the IP model - ICMP
and MTUs

res: reserved

M: more fragments

The new fragment header is always the first header following the IPv4 or
IPv6 header. This means that filtering on protocol and port numbers is
always easy because the information is always present in the same place
in the packet, even if additional headers are present between the new
fragment header and the transport header.

When routers observe a packet with the new fragment header that is too
large to be forwarded, they truncate the packet. The minimum size of the
first fragment is 1280 bytes. Note that traditional IPv4 fragmentation
produces the same result as truncation for the first fragment.

The observed packet length field allows for passive PMTUD. A full PMTUD
implementation can be done by initializing the PMTU to 1280 and then use
a new fragment header for packets larger than the PMTU and/or in
response to incoming packets that updated the OPL, updating the PMTU
from the OPL field in incoming packets, resetting the PMTU after a
retransmission timeout.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 19 Aug 2008 18:21:00 +0200

> do not have to cross EH for upper layer info and also make things work

:-)

> Regarding the position of the header, are you saying this header  

Well, that's the only way to avoid the current situation where  
filtering devices have to hunt for the UDP or TCP header, which they  
either don't do or incurs performance penalties...

---

From: "Chip Popoviciu (cpopovic)" <[email-masked]>
Date: Tue, 19 Aug 2008 12:32:04 -0400

But if the HbH is present, the packet will hit the slow path anyway so
performance penalties are there. If the HbH is not present then the
first header will be the fragmentation header.

Chip

-----Original Message-----
From: Iljitsch van Beijnum [mailto:[email-masked]] 
Sent: Tuesday, August 19, 2008 12:21 PM
To: Chip Popoviciu (cpopovic)
Cc: v6ops Operations
Subject: Re: New fragment header, was: Re: Evolution of the IP model -
ICMP and MTUs

On 19 aug 2008, at 18:17, Chip Popoviciu (cpopovic) wrote:

> Then might as well, put a fragment header on all packets so that 
> routers do not have to cross EH for upper layer info and also make 
> things work with ESP as well.

:-)

> Regarding the position of the header, are you saying this header will 
> be ahead of HbH?

Well, that's the only way to avoid the current situation where filtering
devices have to hunt for the UDP or TCP header, which they either don't
do or incurs performance penalties...

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 19 Aug 2008 17:13:28 -0400

Jeroen Massar wrote:
> most likely can actually resolve your problem? [email-masked] also 
> comes to mind here]

Oh, I am talking a lot on the Centos mailing list.

More just letting a little of my feeling of dismay known to those 
working diligently on deploying IPv6..

But your mention of ipv6.org reminds me that I wanted to go there....

>> starters. I am using the HIPL code in userspace, as the BEET IPsec 
>> patch is not yet in the Centos kernel (BEET is in, but it needs the 
>> patch to work right).
>>
>> So I need IPv6 apps, and have been having a terrible time of it. I 
>> can list where I am so far, if there is interest (or help 
>> available!), but I do not have a single IPv6 client/server app 
>> running yet after two weeks of work.
>
> Then I would suggest that you get a distribution that actually 
> supports IPv6 correctly. Debian (unstable) is doing this already for 
> years.
> experimental/fairly new (HIPL etc) to just be included in a 
> distribution per default.
>
>> Friday, I decided that IPv4 was just getting in my way to find 
>> working IPv6 apps (until I need to test in a Teredo environment), so 
>> I tried to disable IPv4.
>
> will not work. See also the threads on 4to6 and other proposals from 
> the last couple of months on this and other related lists (RRG for 
> instance).
>
>> loopback addresses (even when I commented out all references that I 
>> can find for the IPv4 loopback address).
>
> Systems use the loopback interface for communication, you thus won't 
> be able to turn that off easily for the next couple of years.
>
>> I find this unsettling. Kind of like an IPv4 forevermore position, 
>> with IPv6 kind of sometime.....
>

---

From: Rémi Després <[email-masked]>
Date: Wed, 20 Aug 2008 09:59:14 +0200

Have you considered having an E2E fragmentation header as an option of DCCP?

Then:
- All datagrams would fit in one packet when the option is used (=> no 
tricky performance problem in filtering devices).
- The fragmentation header would be simpler than in your initial 
proposal below (just Identification, Fragment Offset, M).
- Means already available to detect by negociation whether concerned 
nodes, only two in this case, support the option (incremental deployment).
- Applicability in IPv4 and IPv6 without any required modification in 
the IP layer.

DCCP seems to me the right direction for graceful transmission of 
datagrams that exceed path MTUs through filtering devices.

Regards.

Rémi Després

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 20 Aug 2008 10:40:37 +0200

> first header will be the fragmentation header.

Good point. But then it's also no problem to look for the hop-by-hop  
header after the fragment header, right?

> datagrams that exceed path MTUs through filtering devices.

...the port numbers are still only in the first fragment, so filtering  
remains somewhat problematic and NATing very problematic.

---

From: Rémi Després <[email-masked]>
Date: Wed, 20 Aug 2008 11:28:56 +0200

Iljitsch van Beijnum  le (m/j/a) 8/20/08 10:40 AM:
> ...the port numbers are still only in the first fragment,

Well, there remains a terminology ambiguity in the fragmentation DCCP 
option I propose to introduce.
- Let's say that what applications want to send are "User Datagrams", 
and that what DCCP submits to the IP layer are "IP Datagrams".
- Each User Datagram that is too large to fit in an PMTU-compatible IP 
Datagram is then split by the DCCP layer into several "User Datagram 
Fragments", each one being sent in a single PMTU compatible IP Datagram.
- Since each of these IPDs is Path MTU compatible, it remains E2E as a 
single IP layer fragment. It therefore keeps its DCCP port numbers, 
independently of its being the first or another fragment of its User 
Datagram.

> so filtering remains somewhat problematic and NATing very
> problematic.

Not in this case, which it the result that was looked for :-).

Rémi Després

---

From: Francis Dupont <[email-masked]>
Date: Wed, 20 Aug 2008 22:12:49 +0200

In your previous mail you wrote:

=> I deeply disagree: what is needed here is a fragmentation (or
segmentation) at the transport level, not a new network transport-aware
beast. Note, as the issue exists only for UDP, what is needed is
a segmentation capable UDP-like, or, perhaps far easier to deploy,
add in all UDP based applications an application level segmentation
support. The last option is to switch to TCP / SCTP / etc.

Regards

[email-masked]

PS: not local UDP based applications I know are:
 - NFS: simply switch to TCP
 - DNS: with EDNS size negotation, TC bit, DNS over TCP, etc, it should
  work but it seems there are still many problems from not-compliant
  parts.
 - IKE: UDP is a bad choice from the beginning but the message is not
  yet decrypted (:-).
 - Radius: should be local, shouldn't it?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 20 Aug 2008 22:30:04 +0200

On 20 aug 2008, at 22:12, Francis Dupont wrote:

> Note, as the issue exists only for UDP

Note that this fragment header has a broader purpose than current  
fragmentation, even if the above were true for existing fragmentation  
(it isn't, tunneling is an important issue and fragments sometimes  
happen where you wouldn't expect them, even with TCP).

For instance, the new fragment header will allow for a non-ICMP based  
path MTU discovery and easier filtering and NATing because port  
numbers are always in the same place regardless of extra headers, and  
regardless of whether the transport is TCP, UDP, SCTP or DCCP.

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 22 Aug 2008 03:27:12 -0400

Hi Iljitsch,
   I had similar issues to you couple of years ago in going over hop by 
hop options to get to the transport layer port information. And one 
solution I thought of  was exactly the same as you. But I eventually 
realized it does not work very well. e.g. What happens if the eventual 
transport ports as seen by the end host do not match wth the fragment 
header`s. This would be a firewall bypass vector.

Thanks
Suresh

Iljitsch van Beijnum wrote:
> path MTU discovery and easier filtering and NATing because port numbers 
> are always in the same place regardless of extra headers, and regardless 
> of whether the transport is TCP, UDP, SCTP or DCCP.
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 22 Aug 2008 09:52:55 +0200

On 22 aug 2008, at 9:27, Suresh Krishnan wrote:

>  I had similar issues to you couple of years ago in going over hop  
> by hop options to get to the transport layer port information. And  
> one solution I thought of  was exactly the same as you. But I  
> eventually realized it does not work very well. e.g. What happens if  
> the eventual transport ports as seen by the end host do not match  
> wth the fragment header`s. This would be a firewall bypass vector.

Well, the first thing that always comes to my mind in these situations  
is the adage "so don't do that." (I.e., take the new fragment header  
ports at face value.)

I was considering mandating that the transport port numbers be zeroed  
out so that they must be copied back from the new fragment header by  
the receiver...

Another option would be to compress the transport headers. But I  
didn't want to make the thing overly complex.  :-)

Iljitsch