Subject: I-D Action: draft-ietf-6man-deprecate-atomfrag-generation-03.txt

From: [email-masked]
Date: Sat, 04 Jul 2015 01:37:07 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

        Title           : Deprecating the Generation of IPv6 Atomic Fragments
        Authors         : Fernando Gont
                          Will(Shucheng) Liu
                          Tore Anderson
	Filename        : draft-ietf-6man-deprecate-atomfrag-generation-03.txt
	Pages           : 10
	Date            : 2015-07-04

Abstract:
   The core IPv6 specification requires that when a host receives an
   ICMPv6 "Packet Too Big" message reporting an MTU smaller than 1280
   bytes, the host includes a Fragment Header in all subsequent packets
   sent to that destination, without reducing the assumed Path-MTU.  The
   simplicity with which ICMPv6 "Packet Too Big" messages can be forged,
   coupled with the widespread filtering of IPv6 fragments, results in
   an attack vector that can be leveraged for Denial of Service
   purposes.  This document briefly discusses the aforementioned attack
   vector, and formally updates RFC2460 such that generation of IPv6
   atomic fragments is deprecated, thus eliminating the aforementioned
   attack vector.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-deprecate-atomfrag-generation/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-deprecate-atomfrag-generation-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Fernando Gont <[email-masked]>
Date: Sat, 04 Jul 2015 05:40:20 -0300

Folks,

This revision essentially removes the updates to RFC6145, since the
corresponding changes has been incorporated in the RFC6145bis effort
(draft-bao-v6ops-rfc6145bis-00.txt).

I think this I-D is now ready to be progressed (WGLC'ed).

Thanks!

Best regards,
Fernando

On 07/04/2015 05:37 AM, [email-masked] wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

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

---

From: Ole Troan <[email-masked]>
Date: Tue, 7 Jul 2015 13:33:20 +0200

Fernando,

> I think this I-D is now ready to be progressed (WGLC'ed).

as a part of evaluating the errata and updated-by RFCs for making RFC2460 full standard, it appears to me that we have to re-issue RFC2460.
my current thinking is to incorporate the changes proposed in deprecate-atomfrag-generation in an RFC2460bis.

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Tue, 07 Jul 2015 12:47:19 -0300

Hi, Ole,

On 07/07/2015 08:33 AM, Ole Troan wrote:
> 
>> This revision essentially removes the updates to RFC6145, since
>> the corresponding changes has been incorporated in the RFC6145bis
>> effort (draft-bao-v6ops-rfc6145bis-00.txt).
>> 
> as a part of evaluating the errata and updated-by RFCs for making
> RFC2460 full standard, it appears to me that we have to re-issue
> RFC2460. my current thinking is to incorporate the changes proposed
> in deprecate-atomfrag-generation in an RFC2460bis.

A few comments:

* If anything, I'd apply this policy to new documents, rather than
existing ones.

* I'm sure other folks (you, Brian C, Brian H, or others) will know
better than me, but I guess that if a RFC2460bis was issued, it wouldn't
move to full standard anytime soon. i.e., we'd have to wait for maturity
of the whole package, because RFC2460bis would reset the "counter" back
to zero.

* There has been a lot of work in the recent years with improvements to
the IPv6 specs. I'd personally wait for at least one year for things to
become more stable, and only then issue RFC2460bis. Otherwise, we'd be
back into the same scenario (now "updates to RFC2460bis"), or we'd just
block improvements in order to avoid that of "coming back to the same
scenario" (and if the plan is to use IPv6 for long enough, that wouldn't
be very sensible).

* It would seem to me that it would even make RFC2460bis go smoother if
it simply incorporates changes that have already settled on RFCs. --
i.e., the changes would have already been reviewed by the IETF
community, and RFC2460bis would just be "RFC2460+updates".

* I'm kind of skeptical myself regarding the impact of moving RFC2460 to
full standard. Or, more clearly, I don't think it would have much of an
impact on IPv6 deployment or implementation. A guy that has not deployed
IPv6 will not deploy it because "IPv6 is now a full standard", in the
same way that a guy that has not implemented IPv6 will not do so just
because of that. At the end of the day, as someone noted, "the Internet
runs on proposed standards".

Thoughts?

Thanks!

Best regards,

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 Jul 2015 10:06:02 +0200

Fernando,

> of the whole package, because RFC2460bis would reset the "counter" back

the intention is to take an updated document directly to Internet standard.

> scenario" (and if the plan is to use IPv6 for long enough, that wouldn't

please don’t make the impression that RFC2460 is in flux, it is not, and it should not be.
in my personal view, although I think it has been useful to get a wart or two removed, we have gone too far with “improvements". RFC2460 is updated by _9_ RFCs, making it unduly hard for anyone trying to implement this.

> community, and RFC2460bis would just be "RFC2460+updates”.

yes, that’s the intention. only errata and updated-by documents.
then we can see if we can make an exception for the atomfrag-generation paragraph. I would hope we didn’t have to publish that as an RFC, just so that we could get the paragraph removed.

> runs on proposed standards”.

I largely agree with that.
we did talk about upgrading 2460 unchanged. I do think doing a revision and incorporating the updated-by and errata improve the document quality. Internet standard does signify stability, which I do think is important, as the whole Internet is going to run over IPv6. that will also imply that we as a community is done with it, and must prohibit ourselves from tinkering with it anymore. which I think is the right thing to do.

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Jul 2015 11:35:19 +1200

On 13/07/2015 20:06, Ole Troan wrote:
...
> I do think doing a revision and incorporating the updated-by and errata improve the document quality.

There is no doubt of that. However, some of the updates are quite complex
in themselves (I apologise for my part in that). It would be cleaner,
if possible, for 2460bis to make normative references to the complex
updates (for example, say nothing about the flow label except
a reference to RFC6437).

   Brian

---

From: Ole Troan <[email-masked]>
Date: Wed, 15 Jul 2015 10:48:36 +0200

Brian,

> updates (for example, say nothing about the flow label except

yes, after having looked at the updates to 2460 it is indeed quite complex.
taking the flow label as an example.
it may be possible to remove section 6 and appendix A and add a reference.
but does RFC6427 meet the criteria in RFC6410 or do we need to do a downref?
2460, section 6 states the flow label is still experimental. perhaps that’s still true. ;-)

at least for 2460 this may be a Pandora’s box.

we have put a slot for this discussion on the agenda for Prague.

cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Wed, 15 Jul 2015 12:53:03 -0300

Hi, Ole,

On 07/13/2015 05:06 AM, Ole Troan wrote:
>> * I'm sure other folks (you, Brian C, Brian H, or others) will
>> know better than me, but I guess that if a RFC2460bis was issued,
>> it wouldn't move to full standard anytime soon. i.e., we'd have to
>> wait for maturity of the whole package, because RFC2460bis would
>> reset the "counter" back to zero.
>

Is it doable? My understanding of the standards process is that it
wouldn't be doable. Some updating documents (such as RFC7045) seem to be
pretty fundamental, and way more than "let's fix this bug in RFC2460".

>> * There has been a lot of work in the recent years with
>> improvements to the IPv6 specs. I'd personally wait for at least
>> one year for things to become more stable, and only then issue
>> RFC2460bis. Otherwise, we'd be back into the same scenario (now
>> "updates to RFC2460bis"), or we'd just block improvements in order
>> to avoid that of "coming back to the same scenario" (and if the
>> plan is to use IPv6 for long enough, that wouldn't be very
>> sensible).
>
> please don’t make the impression that RFC2460 is in flux, it is not,
> and it should not be. in my personal view, although I think it has
> been useful to get a wart or two removed, we have gone too far with
> “improvements". RFC2460 is updated by _9_ RFCs, making it unduly hard
> for anyone trying to implement this.

I disagree in a number of aspects:

* I'm not sure what it means "to be in flux". If it means "to be an
experimental protocol" -- then it certainly isn't. If it means "there
are certain aspects being tightened up", I'd say it is. And that doesn't
speak bad of IPv6. Given that it has only recently we started getting
real deployment experience, testing, etc., that shouldn't be a
surprise.... but rather obvious.

* I don't think "we have gone too far". It's not that we have been
tweaking the protocol because of "neat features that would be cool to
have". We have updated the protocol because there were aspects that
led to trouble if they remained unfixed. For instance, if we're
going to live with IPv6 for at least, say 30 years (as I would
expect), tightening-up the protocol is a good thing, and the sooner, the
better.

* Having implemented IPv6 myself, I'd say the hard part of implementing
it has nothing to do with the 9 (or whatever) updates we have made to
RFC2460. Actually, they have some removed troublesome cornercases, or,
like RFC7045 have allowed real-world implementations to remain compliant.

[...]
>> * I'm kind of skeptical myself regarding the impact of moving
>> RFC2460 to full standard. Or, more clearly, I don't think it would
>> have much of an impact on IPv6 deployment or implementation. A guy
>> that has not deployed IPv6 will not deploy it because "IPv6 is now
>> a full standard", in the same way that a guy that has not
>> implemented IPv6 will not do so just because of that. At the end of
>> the day, as someone noted, "the Internet runs on proposed
>> standards”.
>
> I largely agree with that. we did talk about upgrading 2460
> unchanged. I do think doing a revision and incorporating the
> updated-by and errata improve the document quality. Internet standard
> does signify stability, which I do think is important, as the whole
> Internet is going to run over IPv6. that will also imply that we as a
> community is done with it, and must prohibit ourselves from tinkering
> with it anymore. which I think is the right thing to do.

While it's certainly not for me to judge, I'd probably wait for the
water to calm before making that assertion. Is there are issues being
raised, there's probably a reason for that. Abandoning fixes at this
point in time seems shortsighted to me.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 15 Jul 2015 12:54:24 -0300

Hi, Ole,

[....]
>> * It would seem to me that it would even make RFC2460bis go
>> smoother if it simply incorporates changes that have already
>> settled on RFCs. -- i.e., the changes would have already been
>> reviewed by the IETF community, and RFC2460bis would just be
>> "RFC2460+updates”.
> 
> yes, that’s the intention. only errata and updated-by documents. then
> we can see if we can make an exception for the atomfrag-generation
> paragraph. I would hope we didn’t have to publish that as an RFC,
> just so that we could get the paragraph removed.

IMO, publishing this document is useful for a number of reasons:

1) If you just omit the paragraph in RFC2460bis, you're not signaling
existing implementations that they should stop generating atomic
fragments. Most likely, existing implementations will not be updated.

2) This document provides a rationale for the change. Unless one wants
to incorporate the discussion/rationale in RFC2460bis (probably
undesirable), this I-D can document the rationale, and RFC2460 just
incorporate the update without much discussion and a reference to this
I-D/RFC.

3) Having RFC2460bis just incorporate errata and updating RFCs seems to
be a smoother path, since all updates will have been vetted by the IETF
community already.

4) Given the current state of this document (around for a while, and
stable), that RFC6145bis benefits both from the change and the
rationale, and given the above considerations regarding RFC2460bis, and
that it's unclear the timeframe of publication of RFC2460bis, I'd go on
and publish this document as an RFC.

Thanks!

Cheers,

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 20 Jul 2015 15:22:27 +0200

Hi,

Le 15/07/2015 10:48, Ole Troan a écrit :
>> There is no doubt of that. However, some of the updates are quite
>> complex in themselves (I apologise for my part in that). It would
>> be cleaner, if possible, for 2460bis to make normative references
>> to the complex updates (for example, say nothing about the flow
>> label except a reference to RFC6437).
>
> yes, after having looked at the updates to 2460 it is indeed quite
> complex. taking the flow label as an example. it may be possible to
> remove section 6 and appendix A and add a reference. but does RFC6427
> meet the criteria in RFC6410 or do we need to do a downref? 2460,
> section 6 states the flow label is still experimental. perhaps that’s
> still true. ;-)
>

I dont support nor oppose a 2460bis.

Depending on how it's done, it may be worth considering that Pad0 and
PadN options are rarely if ever used by other protocols.

I think PadN is not used anywhere, but I may be wrong.

Alex

> cheers, Ole
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6