Hi Sri, > -----Original Message----- > From: Sri Gundavelli (sgundave) [mailto:[email protected]] > Sent: Tuesday, September 23, 2014 4:19 PM > To: Templin, Fred L; [email protected] > Subject: Re: Signaling Message Fragmentation > > Hi Fred, > > inline .. > > On 9/23/14 4:14 PM, "Templin, Fred L" <[email protected]> wrote: > > >Hi Sri, > > > >> -----Original Message----- > >> From: Sri Gundavelli (sgundave) [mailto:[email protected]] > >> Sent: Tuesday, September 23, 2014 4:06 PM > >> To: Templin, Fred L; [email protected] > >> Subject: Re: Signaling Message Fragmentation > >> > >> 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. > > > >Probably better to look at the latest AERO spec (posted today). > >I have it fixed there now. > > Ack. Will take a look
OK. > >> 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. > > > >I'm not much of a fan of advertised MTU values in RAs and such. It > >may be OK if your tunnel is point-to-point, but I want good MTU > >solution for NBMA tunnels where the MTU between neighbors A and B > >may be vastly different than the MTU between neighbors A and C. > > > Its a P2P tunnel and so the NBMA considerations may not be needed. What might be needed however is a solution that recurses for deeply-nested tunnels-within-tunnels (remember "nested NEMO"?). AERO tunnels can recurse indefinitely, with a minimum of 1500 seen at each level. > >I also want there to be a guaranteed minimum and an unlimited maximum. > >With AERO, all paths are guaranteed to support a minimum MTU of 1500. > >But, larger packets can also go through (unfragmented) if the path > >MTU is sufficient. > > > Ok. Good. We will need this if we want to push the Internet MTU up to something more robust like 9KB or more. Thanks - Fred [email protected] > Regards > Sri > > > > > > > >Thanks - Fred > >[email protected] > > > >> 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
