Sri,
> I've seen some work on IPSecme WG on IKEv2 message fragmentation
> for the same issue.
I looked at this, and the approach is roughly the same as what I have
been talking about in SEAL [RFC5320][draft-templin-intarea-seal] for
years. In other words, perform fragmentation and reassembly at a level
above the encapsulating IP protocol headers and below the encapsulated
IP protocol headers - a mid-layer fragmentation and reassembly.
So, this brings up a few questions:
1) Does the concern apply only to large control messages, or also to
large data packets?
2) How big can the control messages get - not only for just today but
also going forward into the future?
3) Are we really so concerned about IP fragment dropping that we need
to bump this up to a mid-layer frag/reass?
Thanks - Fred
[email protected]
---
From: dmm [mailto:[email protected]] On Behalf Of Templin, Fred L
Sent: Monday, September 22, 2014 4:45 PM
To: Sri Gundavelli (sgundave); [email protected]
Subject: Re: [DMM] Signaling Message Fragmentation
Hi Sri,
My understanding is that if a source sends fragmented messages it must have
assurance
that the destination has a large enough reassembly buffer. Since the minimum
IPv6
reassembly unit is only 1500 bytes, the source SHOULD NOT send fragmented
packets
larger than 1500 bytes unless there is some other means of determining whether
the
destination's reassembly buffer can accommodate the larger size.
How big do you need?
Thanks - Fred
From: dmm [mailto:[email protected]] On Behalf Of Sri Gundavelli (sgundave)
Sent: Thursday, September 18, 2014 1:04 PM
To: [email protected]
Subject: [DMM] Signaling Message Fragmentation
[Discussion under the maintenance scope]
With the standardization of all the new mobility options (ANI, QoS, IFOM,
MNP..etc) and specially with the NAI/Domain type fields in some of those
options, we are almost close to hitting the PBU/BU fragmentation limit.
Any thoughts on how to deal with this ? How is it solved in other message based
protocols ? I've seen some work on IPSecme WG on IKEv2 message fragmentation
for the same issue.
Should we do some thing here ? Or, if any one has invested time on this and has
a proposal ? Comments ?
Regards
Sri
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
