Subject: Status of Operational issues with Tiny Fragments in IPv6

From: "Vishwas Manral" <[email-masked]>
Date: Fri, 26 May 2006 10:37:20 +0530

Hi Fred,

Thanks a lot for summarizing the issue. I have changed the subject
line to more closely reflect the discussion. Just to remind the people
the discussion on this topic happened more on the ipv6 list than on
the v6ops list.
The way I see the problem is that we have middlebox devices, so that
we do not have to cram all the functionality in each of the end
devices and it also makes the entire thing easier to manage.

A lot of basic attacks(example SYN flood) are detected by seeing
discrepancies in the header fields. For IPv4 firewalls will drop/ send
to slow path packets with IP options and the packet of below 64 bytes
is dropped for non-last fragment. In IPv4 this way we solve the
problem of having the header fields not broken across fragments.

In IPv6 options are now a standard part.of the protocol. We need to
state what the non-last fragment size can be because by doing so we do
not have a way for the attacker to pass the firewall yet be accepted
by an end host.
A simple solution recommended by the IPv6 chairs was to drop all such packets.

Thanks,
Vishwas
On 5/26/06, Fred Baker <[email-masked]> wrote:
> OK, folks. Lets get a review.
>
>    http://www.ietf.org/internet-drafts/draft-manral-v6ops-tiny-
> fragments-issues-02.txt
>   "Operational issues with Tiny Fragments in IPv6", Vishwas Manral,
> 9-Jan-06,
>   <draft-manral-v6ops-tiny-fragments-issues-02.txt>
>
> The principal comment that I noted from our previous discussion was
> that the problem existed for IPv4 also, and hence was not
> specifically an IPv6 problem. The working group did not choose to
> make a recommendation on the topic, and personally I wasn't aware
> that we were asked to. The key recommendation seems to be that there
> be a minimum MTU size large enough to contain the IPv6 header (with
> all of its additional headers) plus the second layer header, and that
> middleware devices like firewalls discard messages that were a non-
> last fragment and were smaller than that size.
>
> In such a case, this would convert the attack to another kind of
> attack, one in which the target is bombarded with fragments of
> messages, but never enabled to reassemble them, and attacking the
> reassembly tables and associated memory. The solution for that is
> fortunately trivial - in the event that there is any any overload in
> this area, discard the oldest fragment in the buffer and any other
> fragments that are presumptively part of the same message - the same
> way we protect TCP TCBs.
>
> The origin of the discussion was in Mobile IP, where related issues
> were addressed.
>
> What do folks wish the document said? Is this something for the
> working group to make an effort on? Is there a feeling that it should
> be a working group draft?
>
>
> On May 24, 2006, at 11:56 PM, Vishwas Manral wrote:
>
> > Hi Fred,
> >
> > I thought it was an important enough issue to be addressed, from
> > the operational perspective.
> >
> > If possible I would want to drive it further. Would be eager to get
> > your views on the same.
> >
> > Thanks for restarting the discussion,
> > Vishwas
> >
> > On 5/24/06, Fred Baker <[email-masked]> wrote:
> > On May 24, 2006, at 12:02 AM, Vishwas Manral wrote:
> >
> > > I am not sure the draft http://www.ietf.org/internet-drafts/draft-
> > > manral-v6ops-tiny-fragments-issues-02.txt is dead. It still exists
> > > in the IETF repository.
> >
> > Yes, it is in the repository; it remains until they flush it out.
> > What I was saying is that discussion seems to be at an end.
> >
> > What would you like to do with it further? Do you plan to continue
> > driving this?
> >
>

---

From: Elwyn Davies <[email-masked]>
Date: Fri, 26 May 2006 09:21:51 +0100

These issues are already discussed in sections 2.1.10 and 2.1.11 of 
draft-v6ops-security-overview-04.

I didn't get involved too much in the discussion of Vishwas' draft 
because I had already been round the loop of suggesting to the ipv6 wg 
that the base standard should be modified to recommend
- no overlapping fragments and
- non-last fragments to be close to the guaranteed minimum MTU.

This didn't get much traction.  However the concerns are valid.

I would suggest that rather than making this into a separate draft we 
can look at improving the text in the security overview (if necessary) 
given that we are probably ging to have to do *another* round on this one.

Regards,
Elwyn

---

From: "Vishwas Manral" <[email-masked]>
Date: Fri, 26 May 2006 14:50:23 +0530

Hi Elwyn,

I did notice the issue being raised in the security overview section.

Firstly it is not just a security issue but issue for all middle
boxes. Also I think security overview probably is not the best place
to specify the solution to the problem. The point I bring forward is
that we need not just a problem statement but also a solution of how
to deal with it.

Do let me know if I am off target.

Thanks,
Vishwas

---

From: Pekka Savola <[email-masked]>
Date: Fri, 26 May 2006 18:05:41 +0300 (EEST)

> that we need not just a problem statement but also a solution of how

FWIW, I agree that we can describe the problem (which is mostly 
security-related) in the overview, and already do, to some extent.

This is our charter items 2 and 3.  This WG isn't chartered to specify 
(in the normative sense, e.g., altering RFC 2460) the solution, it 
should likely be done by IPv6 WG or an int-area work item.  I'd fully 
support a clean-up of the IPv6 specification (including more than just 
this issue), but I think folks need to talk to the Internet ADs on 
whether they feel this is the right thing to do and which way to go 
about doing it.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Fred Baker <[email-masked]>
Date: Fri, 26 May 2006 08:31:30 -0700

On May 26, 2006, at 1:21 AM, Elwyn Davies wrote:
> I would suggest that rather than making this into a separate draft  
> we can look at improving the text in the security overview (if  
> necessary) given that we are probably going to have to do *another*  
> round on this one.

That seems rational to me.

> - non-last fragments to be close to the guaranteed minimum MTU.

I think the latter point wants to read "non-last fragments close to  
the PATH MTU, and therefore at least as large as the largest fragment  
size less than or equal in size to the minimum MTU."

There is a discussion of fragmentation and reassembly in RFC 1812  
section 4.2.2.7 that may be useful to reference, or at least learn  
lessons from. In part, this results from the behavior of NIC cards in  
the late 1980's that couldn't reliably receive datagrams back to back  
for very long due to chip or memory issues, and partly this is is due  
to brain-dead behaviors in early end-station OS's. One issue was that  
many systems sent packets at the minimum MTU size (then 576 bytes,  
derived from the memory structure of the Fuzzball and BBN Routers)  
rather than at the path MTU, which meant that there were greater  
opportunities for per-datagram errors because there were more of  
them. There were also various strategies on how to fragment - should  
the first datagram be the smallest, the last, or should the  
fragmenting system try to make them all approximately the same size?  
It makes some specific recommendations:

> 4.2.2.7 Fragmentation: RFC 791 Section 3.2
>
>    Fragmentation, as described in [INTERNET:1], MUST be supported by a
>    router.
>
>    When a router fragments an IP datagram, it SHOULD minimize the  
> number
>    of fragments.  When a router fragments an IP datagram, it SHOULD  
> send
>    the fragments in order.  A fragmentation method that may  
> generate one
>    IP fragment that is significantly smaller than the other MAY cause
>    the first IP fragment to be the smaller one.
>
>    DISCUSSION
>       There are several fragmentation techniques in common use in the
>       Internet.  One involves splitting the IP datagram into IP
>       fragments with the first being MTU sized, and the others being
>       approximately the same size, smaller than the MTU.  The  
> reason for
>       this is twofold.  The first IP fragment in the sequence will be
>       the effective MTU of the current path between the hosts, and the
>       following IP fragments are sized to minimize the further
>       fragmentation of the IP datagram.  Another technique is to split
>       the IP datagram into MTU sized IP fragments, with the last
>       fragment being the only one smaller, as described in  
> [INTERNET:1].
>
>       A common trick used by some implementations of TCP/IP is to
>       fragment an IP datagram into IP fragments that are no larger  
> than
>       576 bytes when the IP datagram is to travel through a router.
>       This is intended to allow the resulting IP fragments to pass the
>       rest of the path without further fragmentation.  This would,
>       though, create more of a load on the destination host, since it
>       would have a larger number of IP fragments to reassemble into  
> one
>       IP datagram.  It would also not be efficient on networks  
> where the
>       MTU only changes once and stays much larger than 576 bytes.
>       Examples include LAN networks such as an IEEE 802.5 network  
> with a
>       MTU of 2048 or an Ethernet network with an MTU of 1500).
>
>       One other fragmentation technique discussed was splitting the IP
>       datagram into approximately equal sized IP fragments, with the
>       size less than or equal to the next hop network's MTU.  This is
>       intended to minimize the number of fragments that would result
>       from additional fragmentation further down the path, and assure
>       equal delay for each fragment.
>
>       Routers SHOULD generate the least possible number of IP  
> fragments.
>
>       Work with slow machines leads us to believe that if it is
>       necessary to fragment messages, sending the small IP fragment
>       first maximizes the chance of a host with a slow interface of
>       receiving all the fragments.

I think the NIC card issue (where should the smallest fragment be?)  
is historical and not to be worried about. But the matter of  
generating (by whatever algorithm) the least number of fragments that  
can represent a transport-level message is, I think, important.

---

From: Fred Baker <[email-masked]>
Date: Fri, 26 May 2006 08:33:15 -0700

On May 26, 2006, at 8:05 AM, Pekka Savola wrote:
> This WG isn't chartered to specify (in the normative sense, e.g.,  
> altering RFC 2460) the solution, it should likely be done by IPv6  
> WG or an int-area work item.

Except that IPv6 sent it to us. I believe that they view it as an  
operational question.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 26 May 2006 09:46:54 -0700

> for very long due to chip or memory issues,

Digital Equipment Corporation had such NIC cards in the
late 1980's. The DEQNA card in particular could go into
"qe restart" mode when it received back to back fragments
that arrived too quickly for its little legs to carry.
This was exacerbated by packetization mechanisms such as
NFS that sent 8KB frames as chains of back-to-back IPv4
fragments. The follow-on DELQA card, as well as "faster"
VAX processors, improved the situation.    

> and partly this is is due  
> to brain-dead behaviors in early end-station OS's.

Having authored some of the network drivers in one of
those "brain-dead" OSs, there was really nothing that
could be done for the DEQNA case. Ethernet of that day
and age was supposed to be 10Mb/sec, but SUN was one
of the first vendors that could actually achieve
that rate. Times have certainly changed.

Fred
[email-masked]

---

From: Fred Baker <[email-masked]>
Date: Fri, 26 May 2006 09:59:54 -0700

yes. And DEQNA was in no sense the only one; Cisco routers to this  
day have a capability in RIP to insert time delays between RIP  
updates due to issues in Netware, in which some PC NICs had trouble  
with back to back packets. As I say, those were different days.

The matter of minimizing the number of packets required to represent  
a transport message, however, remains real. Especially in wireless  
networks, there are a number of issues that result in a per-datagram  
probability of loss that is to some degree independent of datagram  
size. Sending less network layer datagrams per transport message  
improves the probability of delivering the entire transport message.  
That is the bottom line of the inspecific ruminations people  
frequently make about "fragmentation problems" and preferring  
transport-layer fragmentation and reassembly to network-layer  
fragmentation and reassembly. So it seems like carrying that  
recommendation forward has value.

On May 26, 2006, at 9:46 AM, Templin, Fred L wrote:
>> lessons from. In part, this results from the behavior of NIC cards  
>> in the late 1980's that couldn't reliably receive datagrams back  
>> to back for very long due to chip or memory issues,
>
> Digital Equipment Corporation had such NIC cards in the late  
> 1980's. The DEQNA card in particular could go into "qe restart"  
> mode when it received back to back fragments that arrived too  
> quickly for its little legs to carry. This was exacerbated by  
> packetization mechanisms such as NFS that sent 8KB frames as chains  
> of back-to-back IPv4 fragments. The follow-on DELQA card, as well  
> as "faster" VAX processors, improved the situation.
>
>> and partly this is is due to brain-dead behaviors in early end- 
>> station OS's.
>
> Having authored some of the network drivers in one of those "brain- 
> dead" OSs, there was really nothing that could be done for the  
> DEQNA case. Ethernet of that day and age was supposed to be 10Mb/ 
> sec, but SUN was one of the first vendors that could actually  
> achieve that rate. Times have certainly changed.
>
> Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 26 May 2006 10:05:57 -0700

Then you probably remember Ethernet "trailers" too; they
were required for certain hardware that could only do DMA
when the data was aligned on a page-sized boundary. But
I digress...

Fred

---

From: Fred Baker <[email-masked]>
Date: Fri, 26 May 2006 11:03:26 -0700

On May 26, 2006, at 10:05 AM, Templin, Fred L wrote:
> Then you probably remember Ethernet "trailers" too

all too well. There were great discussions of the degree to which  
they improved things. On some hardware, they reportedly vastly  
increased throughput; on other hardware, they made no difference  
whatsoever. On a router I designed in that timeframe (the company now  
being defunct), I provided the practical option of treating trailers  
as there for the convenience of the sender more than the receiver,  
and therefore converting from trailer to header format in the router.

There are days I feel old. It would be better to feel wise, but my  
experience with people whose opinion of themselves is that they are  
wise is that their estimate of themselves often exceeds other  
opinions of them :-)

---

From: Mark Smith <[email-masked]>
Date: Sat, 27 May 2006 20:19:55 +0930

On Fri, 26 May 2006 11:03:26 -0700

> > Then you probably remember Ethernet "trailers" too
<snip>
> wise is that their estimate of themselves often exceeds other  

What a wise thing to say ;-)

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 29 May 2006 09:50:43 -0400

I may be missing the issue in the draft but I take the main issue to be
as follows:

From section 4 of the spec
>Having tiny fragments could mean that none of the fragments would be
the Initial 
>Fragment. So any access control/ tunneling based onthat may not work
unless reassembly >is done, or extra state like nextHeader  and previous
header length remaining are kept >across fragments.

My first thought now is this is life with IPv4 or IPv6.  Packet assembly
and reassembly is required.  The spec does not provide for me why this
cannot be done from an IETF protocol view for IPv6.

Is this an implementation problem and not IETF specification problem,
thus it was correct to send it to v6ops to do logic check if there is
anything we can do operationally to address the stated issue.

I don't think this spec should even move forward, but again maybe I am
missing the issue that is other than the mid box doing normal packet
reassembly for IPv6?

NB: Also if the packet was encrypted with IPsec many of the security
issues are addressed and also the entire notion of Firewalls for
implementation (as opposed to IETF standardization) is current
discussion in multiple market vertical segments how end-to-end with
IPsec is implemented when Firewalls are present.

Best,
/jim

---

From: Stig Venaas <[email-masked]>
Date: Mon, 29 May 2006 15:53:34 +0200

Fred Baker wrote:
>> can look at improving the text in the security overview (if  

Me too. As Pekka said any normative changes to the IPv6 protocol would 
probably have to go elsewhere anyway.

>> - no overlapping fragments and

Overlapping fragments is the main problem IMO. I would have liked this 
to be banned so that implementations can just drop such packets. Of 
course some hosts might still accept them, and e.g. a firewall would 
need to keep some state to detect overlap.

> I think the latter point wants to read "non-last fragments close to  the 
> PATH MTU, and therefore at least as large as the largest fragment  size 
> less than or equal in size to the minimum MTU."

The draft doesn't talk about overlap, but talks about this latter point. 
Unless overlap is forbidden, a minimum size alone is not sufficient. You 
might have an initial fragment containing most of the datagram (of 
sufficient size), and then have a second overlapping one that overwrites 
parts of the header.

Whatever minimum size we set, one may add so many extension headers that 
e.g. the transport header does not go into the first fragment anyway.

If a minimum fragment size is specified, then I think it should be about 
half the minimum MTU. Rather than using the MTU for all fragments but 
the last, it might make sense to distribute the data evenly so that all 
fragments are roughly the same size. See below.

> opportunities for per-datagram errors because there were more of  them. 
> There were also various strategies on how to fragment - should  the 
> first datagram be the smallest, the last, or should the  fragmenting 
> system try to make them all approximately the same size?  It makes some 
> specific recommendations:
> 
>>    When a router fragments an IP datagram, it SHOULD minimize the  number
>>    of fragments.  When a router fragments an IP datagram, it SHOULD  send
>>    the fragments in order.  A fragmentation method that may  generate one
>>       approximately the same size, smaller than the MTU.  The  reason for
>>       fragment being the only one smaller, as described in  [INTERNET:1].
>>
>>       fragment an IP datagram into IP fragments that are no larger  than
>>       would have a larger number of IP fragments to reassemble into  one
>>       IP datagram.  It would also not be efficient on networks  where the
>>       Examples include LAN networks such as an IEEE 802.5 network  with a

This latter point is what I'm refering to above.

Also note that as mentioned above, some implementations send fragments 
out of order (e.g. Linux has been known to do this). The reason is that 
you don't know the total size of the datagram until you receive the last 
fragment. Receiving the last fragment first means that you can allocate 
the right amount of memory immediately.

Stig

>>
>>       Routers SHOULD generate the least possible number of IP  fragments.
>>
> I think the NIC card issue (where should the smallest fragment be?)  is 
> historical and not to be worried about. But the matter of  generating 
> (by whatever algorithm) the least number of fragments that  can 
> represent a transport-level message is, I think, important.
>

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 30 May 2006 10:35:38 +0530

Hi Jim,

You raise a valid concern.

The issue I see in my view came up when working on firewalls in the
Fastpath. I figured out that in IPv4 the header options are optional,
so packets with options are either sent to the slow path or are
dropped(the more common case). This also means that a non-last
fragment of less than 64 bytes can easily be dropped(which means that
we will have the TCP header in the first fragmet), so most TCP and
transport level header checks like TCP-SYN attacks can be easily
detected. Even a simple 5 tuple based check may not work.

In IPv6, however the extension headers are part of the base protocol
and as we do not have a minimum length for non-last fragment, there is
no way to guarantee that the TCP header is present in the first
header. So basic checks as above cannot be done easily.

That said, for IPsec ESP tunnelled packets(for AH the header inside
can always be looked into) the IPsec authentication at the device
doing the decryption will guarantee that the packet is valid. Note
with RFC4301 the authentication itself is a MUST for ESP now.

Do let me know if I am missing the point altogather?

Thanks,
Vishwas

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 30 May 2006 11:22:16 -0400

Hi Vishwas,

My first question was if the issue is not doing complete packet
reassembly and as I see that issue it simply is a requirement for any
node receiving an end-to-end set of fragments the way it is done with
IPv6.  Once the packet is assembled and processed then this next issue
requires analysis, but the next header values can assist with locating
upper layer headers but RFC 2460 is pretty clear on receivers:

From RFC 2460:

Therefore, extension headers must
   be processed strictly in the order they appear in the packet; a
   receiver must not, for example, scan through a packet looking for a
   particular kind of extension header and process that header prior to
   processing all preceding ones.

A firewall or intrusion detection need to make certain implementation
decisions as they are typically not the end receiver per RFC 2460.  The
question really is when an extension header does not apply to the
implementation it can by pass that extension?

But from RFC 2460:

If, as a result of processing a header, a node is required to proceed
   to the next header but the Next Header value in the current header is
   unrecognized by the node, it should discard the packet and send an
   ICMP Parameter Problem message to the source of the packet, with an
   ICMP Code value of 1 ("unrecognized Next Header type encountered")
   and the ICMP Pointer field containing the offset of the unrecognized
   value within the original packet.  The same action should be taken if
   a node encounters a Next Header value of zero in any header other
   than an IPv6 header.

So I view the issue possibly not one of tiny fragments as all because
nodes need to do packet assembly, but how do secure interim nodes
process ext headers before the next header these secure interim nodes
require.

My answer is as follows.  The node IP stack implementation must adhere
to the spec.  But, the IETF makes no requirement at all what users
implement or any other standards body, as all we really provide is the
opportunity and ability for things to work correctly from our
specifications. Firewalls or edge Intrusion Detection
devices/software/sensors are anomaly's within the users environment to
protect them beyond what open networking standards define.  Thus, in
this case of implementations that want to do next header scan as for a
Firewall it is certainly possible and in my humble "individual" (not HP)
opinion valid code path, or as you stated fast-path. 

End result is not clear. There is an issue but lets see what other v6ops
persons think as again maybe I am just missing the forest for the trees,
but it is not the IETF or any standards bodies business to mandate use
to the market that is their prerogative to accept or alter anything we
provide them from the IETF.

Hope this helps,
/jim

> From: Vishwas Manral [mailto:[email-masked]] 
> Sent: Tuesday, May 30, 2006 1:06 AM
> To: Bound, Jim
> Cc: Fred Baker; Templin, Fred L; Elwyn Davies; [email-masked]
> The issue I see in my view came up when working on firewalls 
> in the Fastpath. I figured out that in IPv4 the header 
> options are optional, so packets with options are either sent 
> to the slow path or are dropped(the more common case). This 
> also means that a non-last fragment of less than 64 bytes can 
> easily be dropped(which means that we will have the TCP 
> header in the first fragmet), so most TCP and transport level 
> header checks like TCP-SYN attacks can be easily detected. 
> Even a simple 5 tuple based check may not work.
> 
> In IPv6, however the extension headers are part of the base 
> protocol and as we do not have a minimum length for non-last 
> fragment, there is no way to guarantee that the TCP header is 
> present in the first header. So basic checks as above cannot 
> be done easily.
> 
> That said, for IPsec ESP tunnelled packets(for AH the header 
> inside can always be looked into) the IPsec authentication at 
> the device doing the decryption will guarantee that the 
> packet is valid. Note with RFC4301 the authentication itself 
> is a MUST for ESP now.
> 
> > I may be missing the issue in the draft but I take the main 
> issue to 
> > be as follows:
> >
> > unless reassembly >is done, or extra state like nextHeader  and 
> > previous header length remaining are kept >across fragments.
> >
> > My first thought now is this is life with IPv4 or IPv6.  Packet 
> > assembly and reassembly is required.  The spec does not 
> provide for me 
> > why this cannot be done from an IETF protocol view for IPv6.
> >

---

From: Fred Baker <[email-masked]>
Date: Tue, 30 May 2006 08:27:37 -0700

On May 29, 2006, at 6:53 AM, Stig Venaas wrote:
> Also note that as mentioned above, some implementations send  
> fragments out of order (e.g. Linux has been known to do this). The  
> reason is that you don't know the total size of the datagram until  
> you receive the last fragment. Receiving the last fragment first  
> means that you can allocate the right amount of memory immediately.

On that particular point, since packets can be reordered in flight in  
a best effort network, it seems to me that the sender can neither  
prevent packets from arriving last fragment first. a middle box  
cannot accurately detect that the sender did or did not do this, and  
the receiver cannot depend on packets being sent last first. So if it  
happens it happens, but thinking very hard about it sounds like a  
fool's errand. Better to simply hang on to the mblks-or-equivalent  
until the segments have all arrived.

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 30 May 2006 18:07:08 +0200

> until the segments have all arrived.

IMHO NAT's(*) and Firewalls are to treat the IP they are passing as they
are end-hosts. They are in the middle and want to do full packet
analysis/translation/filtering. There have been a number of problems
with firewall vendors making a wrong implementation where it was trivial
to send fragmented packets in such a way that it either caused the
implementation to pass those packets on, while they should have
firewalled those packets.

Thus the sole issue, not issues as in the section title, with firewalls
is that the firewall implementation is broken as it does not handle
fragmented packet assembly properly. If the firewall would properly
handle reassembly then there would be no issue, whatever nice or
not-so-nice people would send to it. If they are passing through
fragments, how sure are they that the receiver actually wanted to
receive this in the first place, or is it just guess work it is doing?
From my point of view this is thus a real implementation issue, which
might be good to note as informational to the implementators, but not
something that should make all implementations worldwide to change their
behaviour, as they are doing it correctly. Policy Boxes are the same for
me as firewalls, I wonder why they are listed separetely, or do
"Firewalls" not apply any "Policy" ? :)

NAT-PT is (afaik on the list for) deprecation, thus we should not care
about this either. For the ones that want to implement it: act like an
endhost and handle the fragementation in that manner.

As for the proposed solutions, it lists the misses option E:
" Reassemble all the fragments, and transmit the packet on when
  the packet is okay for the policy or translation that needs
  to be applied to it".
as that is what an end host would do also: it would re-assemble the
packet and then pass it on to it's next hop, usually the user-space
application.

Section 6 IMHO is completely bogus as it would mean all the existing
implementation would have to be changed. As there are people still
clinging to ip6.int for instance and that is only DNS, you really think
that all the implementations around the world would start doing this?
Next to that, in case you would have a cellphone or other lowbandwidth
device, eg a network of 100000 sensors on your carpet, you don't want to
send out 1280 bytes instead of only the 40 that you want because of
various concerns like powerconsumption etc. Next to that, what does one
do with the trailing data that should not be there in the first place.
Also, if we would 'align' packets on 1280, we might want to start doing
this for multiples of 1500 etc too at a certain point, the end would
become endless at a certain point.

Adding these changes to IPv6 would IMHO cause more problems than it is
worth, afaik no currently 'nice' implementation causes issues with
fragments in this way, thus it is only to 'protect' against the
not-so-nice implementations, who will try anything they like anyway.
Maybe we could consult RFC3514? :)

Otherwise said: fix the implementations of the middle boxes and warn
them for this issue in the arch rfc's.

(Then again if they did't get that fragments and other weirdly
constructed packets will cause issues with their firewall...)

Greets,
 Jeroen

* = Who came up with the silly idea of making an IPv6 NAT box!?
    If one expects/want NAT then please stick with IPv4, no need
    to start abusing IPv6 for that.

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 31 May 2006 10:08:30 +0530

Hi Jeroen,

You have raised some very valid points. I will add the proposal you
define, "e." to the draft. I also agree and will replace Issues with
issue e.g. "Issues with Policy Boxes" with "Issue with policy boxes"

I am however not sure of the issue you raise with Section 6., as
bogus. I tried reading the text a couple of times, but could not
understand it. The proposal is to make the non-last fragement slightly
lesser than 1280, to address any fragmentation if tunnelling was to be
done. I do not feel it needs to be done that way by all implemntation,
but we can raise the concern that might arise if we make the fragment
size as 1280 or more. Am I missing the point altogather?

Thanks,
Vishwas

On 5/30/06, Jeroen Massar <[email-masked]> wrote:
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> Comment: Jeroen Massar / http://unfix.org/~jeroen/
>

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 31 May 2006 10:17:48 +0530

Hi Jim,

I agree to the holistic issue you raise here.

I guess it can be a policy question and can be left to the
administrator, about what a middle box should do with an extension
header it does not recognize. A good idea would be to drop it(but that
would also mean that the firewalling device needs to be updated when a
new extension header is introduced before any of the end hosts).

Let us hear more from people on the v6ops list.

Thanks,
Vishwas