Hi Fred,
Thanks for your response and also sorry for the delay in catching up on
this thread; Had to focus on some other business.
The issue that I raised is specifically in the context of control plane
messages. Some of the mobility options (Ex: Dynamic Mobile Network Prefix
option in RFC7148) can easily exceed the path MTU size. Each of these
options by itself may not be huge, but multiple instances of the option
can be included in the message. For Mobile Networks use-case, its possible
a mobile node is assigned a set of IPv6 prefixes and based on the count
exceed the MTU limits. As such this should be OK; But ensuring
fragmentation in the MIP layer eliminates issues such as dropped fragments
by mid-level boxes and also fragmentation by on-path nodes. The question
is also not about requiring a huge buffer sizes, but more about handling
messages which are slightly beyond the MTU sizes. I will look at the SEAL
proposal and understand how its handled there.
For user-plane we are covered, the tunnel entry and exit point perform
fragmentation prior to the encapsulation and so generally this should not
cause any issues. We always have the ability to advertise a lower MTU
value on the access link; The MTU value that we advertise on the access
link should be the lower of the link MTU on the WLAN link and the Tunnel
MTU on the MAG-LMA path. This can be achieved by allowing the MAG to
include the adjusted MTU value in the DHCP OFFER and IPv6 Router
Advertisements. However, we realize not all mobile nodes honor the MTU
option in the DHCPOFFER; But, at least on the addressing plane we can
ensure we send the correct MTU values.
RFC 5844: (IPv4 Traffic from the Mobile Node)
" The DHCPOFFER message [RFC2131] sent to the mobile node MUST
include the Interface MTU option [RFC2132]. The DHCP servers in
the Proxy Mobile IPv6 domain MUST be configured to include the
Interface MTU option. The MTU value SHOULD reflect the tunnel MTU
for the bidirectional tunnel between the mobile access gateway and
the local mobility anchor."
RFC 5213: (IPv6 Traffic from the Mobile Node)
3. The mobile access gateway SHOULD add the MTU option, as specified
in [RFC4861], to the Router Advertisement messages that it sends
on the access link. This will ensure the mobile node on the link
uses the advertised MTU value. The MTU value SHOULD reflect the
tunnel MTU for the bi-directional tunnel between the mobile
access gateway and the local mobility anchor. Considerations
from Section 6.9.5 SHOULD be applied for determining the tunnel
MTU value.
Regards
Sri
On 9/23/14 8:50 AM, "Templin, Fred L" <[email protected]> wrote:
>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
