Skip to main content

Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery
RFC 6980

Revision differences

Document history

Date Rev. By Action
2015-10-14
05 (System) Notify list changed from 6man-chairs@ietf.org, draft-ietf-6man-nd-extension-headers@ietf.org, "Robert M. Hinden"  to (None)
2014-12-22
05 Bob Hinden Notification list changed to 6man-chairs@tools.ietf.org, draft-ietf-6man-nd-extension-headers@tools.ietf.org, "Robert M. Hinden" <bob.hinden@gmail.com> from 6man-chairs@tools.ietf.org, draft-ietf-6man-nd-extension-headers@tools.ietf.org
2014-12-22
05 Bob Hinden Document shepherd changed to Robert M. Hinden
2013-08-13
05 (System) RFC published
2013-08-12
05 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2013-07-11
05 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2013-06-25
05 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2013-06-04
05 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent
2013-06-03
05 (System) RFC Editor state changed to EDIT
2013-06-03
05 (System) Announcement was received by RFC Editor
2013-06-03
05 (System) IANA Action state changed to No IC from In Progress
2013-06-03
05 (System) IANA Action state changed to In Progress
2013-06-03
05 Amy Vezza State changed to Approved-announcement sent from IESG Evaluation::AD Followup
2013-06-03
05 Amy Vezza IESG has approved the document
2013-06-03
05 Amy Vezza Closed "Approve" ballot
2013-06-03
05 Brian Haberman Ballot approval text was generated
2013-06-03
05 Brian Haberman Ballot writeup was changed
2013-06-02
05 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-06-02
05 Fernando Gont New version available: draft-ietf-6man-nd-extension-headers-05.txt
2013-04-16
04 Brian Haberman State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup
2013-04-08
04 Stephen Farrell
[Ballot comment]

- Used to be discuss point 3:

Adding a pointer to Section 6.4.2 of RFC 3971 from section 5 where
you discuss CPA …
[Ballot comment]

- Used to be discuss point 3:

Adding a pointer to Section 6.4.2 of RFC 3971 from section 5 where
you discuss CPA messages would be good. That bit of 3971 says:

        A single advertisement SHOULD be broken into separately sent
        components if there is more than one certificate in the path,
        in order to avoid excessive fragmentation at the IP layer.

So I'd suggest the following change here:

OLD;

  Nodes SHOULD NOT employ IPv6 fragmentation for sending the following
  messages:

NEW:


  Nodes SHOULD NOT employ IPv6 fragmentation for sending the following
  messages: (See  Section 6.4.2 of RFC 3971)

- Used to be discuss point 4:

section 5 says: "SEND nodes SHOULD NOT employ keys that
would result in fragmented CPA messages." That's wrong since we
don't know what algorithms will be needed in future, nor how
big their keys will need to be.  Its also imprecise, e.g. how
big an RSA public key is ok and how big is not? I think you
need to give some guidance here since otherise implementers are
likely to get this wrong, or just not do it. In addition, not
all those keys are under the control of the SEND nodes, e.g.
intermediate CA keys might be long so how can a SEND node
ensure that it meets this requirement? I suggest the following
replacement:

  SEND nodes and relevant certification authorities SHOULD NOT employ
  keys that would result in fragmented CPA messages.

- Used to be discuss point 5:

Checking if this breaks rfc 6494... You checked and it doesn't
but it'd be good to incluide some text about that, for example
derived from your mail on that:

> I have contacted one of the co-authors of RFC6494 (Roque Gagliano), who
> confirmed that the size of the resulting packets is roughly the same
> (very similar). They did the corresponding math while pursuing RFC6494,
> but didn't include it in the RFC. HOwever, here it is:
>
> Packet size from RFC3971: 1055 to 1066bytes
> Difference resulting from key length: 128 bytes
> IPv6 header: 40 bytes
> ICMPv6 header: 4 bytes
> Total: 1227-1238bytes << 1500 bytes
> (This has been veryfied doing packet sniffing... and I'm attaching a
> sample certificate, kindly provided by Roque Gagliano)




---- older comments


- section 1, 2nd para, says that trust anchors make deployment
hard, but doesn't say why. Given we do have cases where TA
deployment has been done, I think you ought back up the
statement.

- section 2: why the indentation of para 2? It looks like a
quote, but from where?

- section 3, 4th para, "Authorization Delegation Discovery"?
could do with a reference (3971 section 6), and I don't quite
get how this thwarts the attacks but doesn't leave open other
ways to get a node to fall back to unsecured mode, if a node is
configured to do that anyway.
2013-04-08
04 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2013-03-29
04 Adrian Farrel [Ballot comment]
Thank you for adding some good operational advice that addresses my Discuss.
2013-03-29
04 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss
2013-03-25
04 Martin Stiemerling [Ballot comment]
Thanks for addressing my DISCUSS.
2013-03-25
04 Martin Stiemerling [Ballot Position Update] Position for Martin Stiemerling has been changed to No Objection from Discuss
2013-03-22
04 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-03-22
04 Fernando Gont New version available: draft-ietf-6man-nd-extension-headers-04.txt
2013-02-28
03 Tero Kivinen Closed request for Last Call review by SECDIR with state 'No Response'
2013-02-26
03 Brian Haberman Ballot writeup was changed
2013-02-26
03 Brian Haberman Ballot writeup was changed
2013-02-21
03 Cindy Morgan State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation
2013-02-20
03 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2013-02-20
03 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy
2013-02-20
03 Benoît Claise
[Ballot comment]
Apparently, there is no issue with my DISCUSS, as it will not happen in real life. So I cleared.

Thanks for a nice …
[Ballot comment]
Apparently, there is no issue with my DISCUSS, as it will not happen in real life. So I cleared.

Thanks for a nice introduction that gives a summary state of the art of IPv6 ND, related work, and problem statement.

- what is the impact on RFC 6105? I mean: should the L2 doing the IPv6 RA-Guard be blocking those fragmented packets?
Or actually this is solved in http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation-07, which is supposed to be updating RFC 6105? Note: I see [I-D.ietf-6man-nd-extension-headers] in the normative reference from http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation-07 but the reference is not mentioned in the text.
Disclaimer: I have not read draft-ietf-v6ops-ra-guard-implementation
Please discuss this issue with me.


- One editorial issue:

  For example, as noted in
  [I-D.ietf-v6ops-ra-guard-implementation], current RA-Guard
  implementations can be trivially evaded by fragmenting the attack
  packets into multiple fragments, such that the layer-2 device cannot
  find all the necessary information to perform packet filtering in the
  same packet.

The link above points to
  [I-D.ietf-v6ops-ra-guard-implementation] discusses an improvement to
  the RA-Guard mechanism that can mitigate Neighbor Discovery attacks
  that employ IPv6 Fragmentation.

... because [I-D.ietf-v6ops-ra-guard-implementation] is not a link, and is
  thought of being the reference itself.

-
      Some Neighbor Discovery implementations are known to silently
      ignore Router Advertisement messages that employ fragmentation.
      Therefore, splitting the necessary information into multiple RA
      messages (rather than sending a large RA message that is
      fragmented into multiple IPv6 fragments) is probably desirable
      even from an interoperability point of view.

The previous paragraph is indented, so it seems to be a cut/paste from a different document?
If yes, from which document?

-
  SEND packets typically carry more information than traditional
  Neighbor Discovery packets: for example, they include additional
  options such as the CGA option and the RSA signature option.

CGA and RSA?
2013-02-20
03 Benoît Claise [Ballot Position Update] Position for Benoit Claise has been changed to No Objection from Discuss
2013-02-20
03 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner
2013-02-19
03 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2013-02-19
03 Stephen Farrell
[Ballot discuss]
(1) cleared

(2) cleared

(3) Doesn't the SHOULD NOT for certification path advertisement
messages in section 4 essentially make SEND unusable? If so, …
[Ballot discuss]
(1) cleared

(2) cleared

(3) Doesn't the SHOULD NOT for certification path advertisement
messages in section 4 essentially make SEND unusable? If so,
why is that ok? If not, can you explain how a real
certification path can fit in a single packet?

(4) section 4 says: "SEND nodes SHOULD NOT employ keys that
would result in fragmented CPA messages." That's wrong since we
don't know what algorithms will be needed in future, nor how
big their keys will need to be.  Its also imprecise, e.g. how
big an RSA public key is ok and how big is not? I think you
need to give some guidance here since otherise implementers are
likely to get this wrong, or just not do it. In addition, not
all those keys are under the control of the SEND nodes, e.g.
intermediate CA keys might be long so how can a SEND node
ensure that it meets this requirement?

(5) How does this draft work with RFCs 6494, 6495 and 6487?
Would it break deployments using those? Did the WG consider
that? Was there some review from the sidr wg?
2013-02-19
03 Stephen Farrell
[Ballot comment]
- section 1, 2nd para, says that trust anchors make deployment
hard, but doesn't say why. Given we do have cases where TA …
[Ballot comment]
- section 1, 2nd para, says that trust anchors make deployment
hard, but doesn't say why. Given we do have cases where TA
deployment has been done, I think you ought back up the
statement.

- section 2: why the indentation of para 2? It looks like a
quote, but from where?

- section 3, 4th para, "Authorization Delegation Discovery"?
could do with a reference (3971 section 6), and I don't quite
get how this thwarts the attacks but doesn't leave open other
ways to get a node to fall back to unsecured mode, if a node is
configured to do that anyway.
2013-02-19
03 Stephen Farrell Ballot comment and discuss text updated for Stephen Farrell
2013-02-19
03 Martin Stiemerling
[Ballot discuss]
1) cleared -- thanks for the information.

2)
Section 1., paragraph 8:

>    Tools such as NDPMon [NDPMon] and ramond [ramond] aim …
[Ballot discuss]
1) cleared -- thanks for the information.

2)
Section 1., paragraph 8:

>    Tools such as NDPMon [NDPMon] and ramond [ramond] aim at monitoring
>    Neighbor Discovery traffic in the hopes of detecting possible attacks
>    when there are discrepancies between the information advertised in
>    Neighbor Discovery packets and the information stored on a local
>    database. rafixd [rafixd] goes one step further, and tries to
>    mitigate some Neighbor Discovery attacks by sending "correcting"
>    Router Advertisement messages in response to incorrect/malicious
>    Router Advertisement messages.

  sending corrections can open another attack vector, if the
  information believed to be correct is simply wrong. I wouldn't
  add such a recommendation in any form to an IETF standards track
  document. I would even discourage any such action.
2013-02-19
03 Martin Stiemerling
[Ballot comment]
- When reading the draft, I have the feeling that the fragmentation here is causing more issues to the IDS instead of the …
[Ballot comment]
- When reading the draft, I have the feeling that the fragmentation here is causing more issues to the IDS instead of the hosts, but I might be terribly wrong.
2013-02-19
03 Martin Stiemerling Ballot comment and discuss text updated for Martin Stiemerling
2013-02-19
03 Meral Shirazipour Request for Telechat review by GENART Completed: Ready. Reviewer: Meral Shirazipour.
2013-02-18
03 Russ Housley
[Ballot comment]

  In response to the Gen-ART Review by Meral Shirazipour on 29-Jan-2013
  the authors agreed to make some minor changes.  An update …
[Ballot comment]

  In response to the Gen-ART Review by Meral Shirazipour on 29-Jan-2013
  the authors agreed to make some minor changes.  An update with these
  changes has not been posted yet.
2013-02-18
03 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley
2013-02-18
03 Adrian Farrel
[Ballot discuss]
I was just ballotting No Objection, when something in Stephen's Discuss
caught my eye.

It would appear that there might be implementations deployed …
[Ballot discuss]
I was just ballotting No Objection, when something in Stephen's Discuss
caught my eye.

It would appear that there might be implementations deployed that use
fragmentation of neighbor discovery messages (even though, as this
document correctly notes, they could achieve the same result by sending
multiple messages).

Nodes that conform to this document will silently ignore fragmented ND
messages, and that will make them unable to interoperate with deployed
nodes that implemented a standards track RFC in good faith.

While we should be free to modify and fix our protocol specifications,
we usually look to do it in a way that will be backward compatible with
existing deployments, or at least provide a migration path.

Given the quoted text in section 2 (by the way, quoted from where?) it
seems that some existing implementations will have interoperability
problems anyway, and this document is "only" increasing the number of
nodes that will silently ignore ND messages.

Perhaps this can all be addressed with a little advice to the operator
of a node that finds itself unable to be discovered?
2013-02-18
03 Adrian Farrel [Ballot Position Update] New position, Discuss, has been recorded for Adrian Farrel
2013-02-18
03 Benoît Claise
[Ballot discuss]
Operationally, when can the sys admin turn on this feature?
Actually, we have two separate features:
  1. Nodes MUST NOT employ IPv6 …
[Ballot discuss]
Operationally, when can the sys admin turn on this feature?
Actually, we have two separate features:
  1. Nodes MUST NOT employ IPv6 fragmentation for sending any of the
  following Neighbor Discovery and SEcure Neighbor Discovery messages:

  2.  Nodes MUST silently ignore the following Neighbor Discovery and
  SEcure Neighbor Discovery messages if the packets carrying them
  include an IPv6 Fragmentation Header:

1. is straightforward, and could be done at any time, while 2. MUST NOT be done until all the legitimate hosts support 1.
Correct?
Does it imply that we need a way to detect that all legitimate hosts in the network support 1.?
This also leads to question: how do I know which hosts are legitimate or not...
Anyway, my point is that, if 2. is turn on without checking a few things, then it might result in loss of connectivity (example: NS from a legitimate host with fragmented packet)
This document requires some text around that.
2013-02-18
03 Benoît Claise
[Ballot comment]
Thanks for a nice introduction that gives a summary state of the art of IPv6 ND, related work, and problem statement.

- what …
[Ballot comment]
Thanks for a nice introduction that gives a summary state of the art of IPv6 ND, related work, and problem statement.

- what is the impact on RFC 6105? I mean: should the L2 doing the IPv6 RA-Guard be blocking those fragmented packets?
Or actually this is solved in http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation-07, which is supposed to be updating RFC 6105? Note: I see [I-D.ietf-6man-nd-extension-headers] in the normative reference from http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation-07 but the reference is not mentioned in the text.
Disclaimer: I have not read draft-ietf-v6ops-ra-guard-implementation
Please discuss this issue with me.


- One editorial issue:

  For example, as noted in
  [I-D.ietf-v6ops-ra-guard-implementation], current RA-Guard
  implementations can be trivially evaded by fragmenting the attack
  packets into multiple fragments, such that the layer-2 device cannot
  find all the necessary information to perform packet filtering in the
  same packet.

The link above points to
  [I-D.ietf-v6ops-ra-guard-implementation] discusses an improvement to
  the RA-Guard mechanism that can mitigate Neighbor Discovery attacks
  that employ IPv6 Fragmentation.

... because [I-D.ietf-v6ops-ra-guard-implementation] is not a link, and is
  thought of being the reference itself.

-
      Some Neighbor Discovery implementations are known to silently
      ignore Router Advertisement messages that employ fragmentation.
      Therefore, splitting the necessary information into multiple RA
      messages (rather than sending a large RA message that is
      fragmented into multiple IPv6 fragments) is probably desirable
      even from an interoperability point of view.

The previous paragraph is indented, so it seems to be a cut/paste from a different document?
If yes, from which document?

-
  SEND packets typically carry more information than traditional
  Neighbor Discovery packets: for example, they include additional
  options such as the CGA option and the RSA signature option.

CGA and RSA?
2013-02-18
03 Benoît Claise [Ballot Position Update] New position, Discuss, has been recorded for Benoit Claise
2013-02-18
03 Martin Stiemerling
[Ballot comment]
- When reading the draft, I have the feeling that the fragmentation here is causing more issues to the IDS instead of the …
[Ballot comment]
- When reading the draft, I have the feeling that the fragmentation here is causing more issues to the IDS instead of the hosts, but I might be terribly wrong.

- I couldn't find the shepherd write-up here in the datatracker. Gone missing or is it just me?
2013-02-18
03 Martin Stiemerling Ballot comment text updated for Martin Stiemerling
2013-02-18
03 Martin Stiemerling
[Ballot discuss]
1) I'm with Stephen's point 1, about no existing implementations and also deployment experience of this.

2)
Section 1., paragraph 8:

>    …
[Ballot discuss]
1) I'm with Stephen's point 1, about no existing implementations and also deployment experience of this.

2)
Section 1., paragraph 8:

>    Tools such as NDPMon [NDPMon] and ramond [ramond] aim at monitoring
>    Neighbor Discovery traffic in the hopes of detecting possible attacks
>    when there are discrepancies between the information advertised in
>    Neighbor Discovery packets and the information stored on a local
>    database. rafixd [rafixd] goes one step further, and tries to
>    mitigate some Neighbor Discovery attacks by sending "correcting"
>    Router Advertisement messages in response to incorrect/malicious
>    Router Advertisement messages.

  sending corrections can open another attack vector, if the
  information believed to be correct is simply wrong. I wouldn't
  add such a recommendation in any form to an IETF standards track
  document. I would even discourage any such action.
2013-02-18
03 Martin Stiemerling
[Ballot comment]
- When reading the draft, I have the feeling that the fragmentation here is causing more issues to the IDS instead of the …
[Ballot comment]
- When reading the draft, I have the feeling that the fragmentation here is causing more issues to the IDS instead of the hosts, but I might be terribly wrong.
2013-02-18
03 Martin Stiemerling Ballot comment and discuss text updated for Martin Stiemerling
2013-02-18
03 Martin Stiemerling
[Ballot discuss]
1) I'm with Stephen's point 1, about no existing implementations and also deployment experience of this.

2)
Section 1., paragraph 8:

>    …
[Ballot discuss]
1) I'm with Stephen's point 1, about no existing implementations and also deployment experience of this.

2)
Section 1., paragraph 8:

>    Tools such as NDPMon [NDPMon] and ramond [ramond] aim at monitoring
>    Neighbor Discovery traffic in the hopes of detecting possible attacks
>    when there are discrepancies between the information advertised in
>    Neighbor Discovery packets and the information stored on a local
>    database. rafixd [rafixd] goes one step further, and tries to
>    mitigate some Neighbor Discovery attacks by sending "correcting"
>    Router Advertisement messages in response to incorrect/malicious
>    Router Advertisement messages.

  sending corrections can open another attack vector, if the
  information believed to be correct is simply wrong. I wouldn't
  add such a recommendation in any form to an IETF standards track
  document.
2013-02-18
03 Martin Stiemerling
[Ballot comment]
- When reading the draft, I have the feeling that the fragmentation here is causing more issues to the IDS instead of the …
[Ballot comment]
- When reading the draft, I have the feeling that the fragmentation here is causing more issues to the IDS instead of the hosts, but I might be terrible wrong.
2013-02-18
03 Martin Stiemerling [Ballot Position Update] New position, Discuss, has been recorded for Martin Stiemerling
2013-02-18
03 Stephen Farrell
[Ballot discuss]

(1) I'm not comfortable with updating esp 4861 like this when
no implementations of this are known to exist as the write up …
[Ballot discuss]

(1) I'm not comfortable with updating esp 4861 like this when
no implementations of this are known to exist as the write up
says. Wouldn't it be prudent to wait until an implemention is
done and tested before forbidding currently implemented
behaviours? I'll likely clear this when told that its not a
concern, but do want to check.

(2) Section 1 says the attacker can generate lots of
fragemented packets and implies that's a reason why
fragmentation support is a bad idea. Why can't a target node
normally handle fragments but turn off fragment support
handling if it detects an anomoly?  (Such as seeing a spike in
fragments.) Did the WG consider this possibility? If you say
that that'd involve keeping additional state and might impact
on performance then I'll buy that, but I don't know if that's
really the case or not.

(3) Doesn't the SHOULD NOT for certification path advertisement
messages in section 4 essentially make SEND unusable? If so,
why is that ok? If not, can you explain how a real
certification path can fit in a single packet?

(4) section 4 says: "SEND nodes SHOULD NOT employ keys that
would result in fragmented CPA messages." That's wrong since we
don't know what algorithms will be needed in future, nor how
big their keys will need to be.  Its also imprecise, e.g. how
big an RSA public key is ok and how big is not? I think you
need to give some guidance here since otherise implementers are
likely to get this wrong, or just not do it. In addition, not
all those keys are under the control of the SEND nodes, e.g.
intermediate CA keys might be long so how can a SEND node
ensure that it meets this requirement?

(5) How does this draft work with RFCs 6494, 6495 and 6487?
Would it break deployments using those? Did the WG consider
that? Was there some review from the sidr wg?
2013-02-18
03 Stephen Farrell
[Ballot comment]

- section 1, 2nd para, says that trust anchors make deployment
hard, but doesn't say why. Given we do have cases where TA …
[Ballot comment]

- section 1, 2nd para, says that trust anchors make deployment
hard, but doesn't say why. Given we do have cases where TA
deployment has been done, I think you ought back up the
statement.

- section 2: why the indentation of para 2? It looks like a
quote, but from where?

- section 3, 4th para, "Authorization Delegation Discovery"?
could do with a reference (3971 section 6), and I don't quite
get how this thwarts the attacks but doesn't leave open other
ways to get a node to fall back to unsecured mode, if a node is
configured to do that anyway.
2013-02-18
03 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2013-02-17
03 Ron Bonica [Ballot Position Update] New position, Yes, has been recorded for Ronald Bonica
2013-02-17
03 Stewart Bryant
[Ballot comment]
This is a well written draft.

Nit:
If you edit the draft before it goes to the RFC-Editor it could use a scrub …
[Ballot comment]
This is a well written draft.

Nit:
If you edit the draft before it goes to the RFC-Editor it could use a scrub for undefined abreviations. I noticed CPA and RA.
2013-02-17
03 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2013-02-14
03 Jean Mahoney Request for Telechat review by GENART is assigned to Meral Shirazipour
2013-02-14
03 Jean Mahoney Request for Telechat review by GENART is assigned to Meral Shirazipour
2013-02-14
03 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks
2013-02-13
03 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2013-02-11
03 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms
2013-02-06
03 Martin Stiemerling Request for Last Call review by TSVDIR Completed: Ready. Reviewer: Allison Mankin.
2013-02-05
03 Brian Haberman Placed on agenda for telechat - 2013-02-21
2013-02-05
03 Brian Haberman State changed to IESG Evaluation from Waiting for AD Go-Ahead
2013-02-05
03 Brian Haberman Ballot has been issued
2013-02-05
03 Brian Haberman [Ballot Position Update] New position, Yes, has been recorded for Brian Haberman
2013-02-05
03 Brian Haberman Created "Approve" ballot
2013-02-05
03 Brian Haberman Ballot writeup was changed
2013-01-29
03 (System) State changed to Waiting for AD Go-Ahead from In Last Call
2013-01-24
03 Pearl Liang
IANA has reviewed draft-ietf-6man-nd-extension-headers-03, which is
currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there …
IANA has reviewed draft-ietf-6man-nd-extension-headers-03, which is
currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need completion.
2013-01-17
03 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2013-01-17
03 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2013-01-17
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Sandra Murphy
2013-01-17
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Sandra Murphy
2013-01-16
03 Wesley Eddy Request for Last Call review by TSVDIR is assigned to Allison Mankin
2013-01-16
03 Wesley Eddy Request for Last Call review by TSVDIR is assigned to Allison Mankin
2013-01-15
03 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Security Implications of IPv6 Fragmentation with …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery) to Proposed Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'Security Implications of IPv6 Fragmentation with IPv6 Neighbor
  Discovery'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-01-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document analyzes the security implications of employing IPv6
  fragmentation with Neighbor Discovery (ND) messages.  It updates RFC
  4861
such that use of the IPv6 Fragmentation Header is forbidden in
  all Neighbor Discovery messages, thus allowing for simple and
  effective counter-measures for Neighbor Discovery attacks.  Finally,
  it discusses the security implications of using IPv6 fragmentation
  with SEcure Neighbor Discovery (SEND), and formally updates RFC 3971
  to provide advice regarding how the aforementioned security
  implications can be prevented.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6man-nd-extension-headers/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6man-nd-extension-headers/ballot/


No IPR declarations have been submitted directly on this I-D.


2013-01-15
03 Amy Vezza State changed to In Last Call from Last Call Requested
2013-01-15
03 Brian Haberman Last call was requested
2013-01-15
03 Brian Haberman Last call announcement was generated
2013-01-15
03 Brian Haberman Ballot approval text was generated
2013-01-15
03 Brian Haberman Ballot writeup was generated
2013-01-15
03 Brian Haberman State changed to Last Call Requested from AD Evaluation
2013-01-14
03 Fernando Gont New version available: draft-ietf-6man-nd-extension-headers-03.txt
2012-12-12
02 Brian Haberman State changed to AD Evaluation from Publication Requested
2012-12-11
02 Brian Haberman Intended Status changed to Proposed Standard
2012-12-11
02 Brian Haberman IESG process started in state Publication Requested
2012-12-11
02 (System) Earlier history may be found in the Comment Log for draft-gont-6man-nd-extension-headers
2012-12-10
02 Bob Hinden IETF state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2012-12-10
02 Bob Hinden Changed protocol writeup
2012-12-09
02 Fernando Gont New version available: draft-ietf-6man-nd-extension-headers-02.txt
2012-12-04
01 Bob Hinden Changed shepherd to Robert Hinden
2012-12-04
01 Bob Hinden IETF state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2012-11-05
01 Fernando Gont New version available: draft-ietf-6man-nd-extension-headers-01.txt
2012-10-04
00 Bob Hinden IETF state changed to In WG Last Call from WG Document
2012-06-29
00 Bob Hinden Started working group last call.
2012-06-29
00 Fernando Gont New version available: draft-ietf-6man-nd-extension-headers-00.txt