Subject: RE: AD Evaluation: draft-ietf-6man-ipv6-atomic-fragments

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 14 Jan 2013 11:31:12 -0800

Hello Fernando,

> -----Original Message-----
> From: Fernando Gont [mailto:[email-masked]]
> Sent: Thursday, December 20, 2012 9:09 PM
> To: Templin, Fred L
> Cc: [email-masked]; 6man WG
> Subject: Re: AD Evaluation: draft-ietf-6man-ipv6-atomic-fragments
> 
> On 12/20/2012 03:04 PM, Templin, Fred L wrote:
> >> On 12/18/2012 04:13 PM, Templin, Fred L wrote:
> >>> I have a question about this document. Is a middlebox permitted
> >>> to fragment an "atomic" fragment before forwarding the packet
> >>> on to the next hop? If not, why not - after all, that's why the
> >>> host inserted the fragment header in the first place.
> >>
> >> My take is that an *IPv6* middle-box is not permitted to fragment the
> >> packet. The IPv6/IPv4 translator is, from an IPv6 point of view, a
> >> host/end-point/end-system (that's where the v6 world ends for that
> >> packet).
> >
> > On further thought, I don't fully accept the notion that the
> > translator is a host/end-point/end-system.
> 
> From the pov of the IPv6 network that's where the packet "ends".
> 
> 
> > The IPv6 host provides
> > the translator with an Identification value, and that value carries
> > forward into the IPv4 world. So, while the IPv6 packet itself does
> > not carry forward, IPv6 information does.
> 
> Yes and no -- e.g., you cannot use the full 32-bit Frag ID.
> 
> 
> 
> >> As to the "why not", I'd guess the reason is "only IPv6 hosts fragment
> >> packets"
> >
> > I think there would need to be an asterisk next to that statement
> > saying that IPv6/IPv4 translators are exempt from this requirement.
> > And, if the translator can be exempt then so also should an IPv6
> > middlebox that connects to a link that would otherwise be obliged
> > to perform burdensome link adaptation.
> 
> This does not only apply to tunnels. One could think of some radio
> devices, embedded systems, etc., for which an adaptation layer would
> possible be overkill. -- So you're idea sounds, at least in principle,
> sensible to me.
> 
> I will review your I-D and will come back with some feedback.

I was wondering if you have had a chance to look at my document
on "IPv6 Path MTU Updates" yet:

https://datatracker.ietf.org/doc/draft-generic-6man-tunfrag/

I have posted a new version since we spoke last, which clarifies
a number of points and now speaks more generically about links
that perform link adaptation rather than just about tunnels. I
would welcome your comments on the document.

Thanks - Fred
[email-masked]

> Thanks!
> 
> Best regards,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [email-masked]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 14 Jan 2013 16:39:00 -0300

> would welcome your comments on the document.

My apologies -- I promise I'll post my feedback no later than the next
couple of days.

Thanks!

Best regards,

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 28 Jan 2013 10:16:19 -0800

Hi Fernado,

Any progress on this?

Thanks - Fred

> Sent: Monday, January 14, 2013 11:39 AM
> To: Templin, Fred L
> Cc: 6man WG
> Subject: draft-generic-6man-tunfrag (was: Re: AD Evaluation: draft-ietf-
> 6man-ipv6-atomic-fragments)
>