Subject: 6MAN WG Last Call: <draft-ietf-6man-nd-extension-headers-00.txt>

From: Bob Hinden <[email-masked]>
Date: Thu, 4 Oct 2012 14:53:08 -0700

All,

This message starts a two week 6MAN Working Group on advancing:

	Title           : Security Implications of the Use of IPv6 Extension Headers with IPv6 Neighbor Discovery
	Author(s)       : Fernando Gont
	Filename        : draft-ietf-6man-nd-extension-headers-00.txt
	Pages           : 12
	Date            : 2012-06-29

       http://tools.ietf.org/html/draft-ietf-6man-nd-extension-headers-00

as Proposed Standard.  Substantive comments and statements of support for advancing this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This last call will end on 18 October 2012.

Regards,

Bob Hinden & Ole Trøan

---

From: Ray Hunter <[email-masked]>
Date: Fri, 05 Oct 2012 22:01:46 +0200

Support.

Bob Hinden wrote:
> Bob Hinden&  Ole Trøan

---

From: james woodyatt <[email-masked]>
Date: Tue, 09 Oct 2012 11:09:10 -0700

> as Proposed Standard.  Substantive comments and statements of support for advancing this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This la…

I support.

--
james woodyatt <[email-masked]>
core os networking

---

From: Rui Paulo <[email-masked]>
Date: Tue, 09 Oct 2012 12:25:26 -0700

I support.

--
Rui Paulo

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 10 Oct 2012 12:43:42 -0700 (PDT)

Hi,

----- Original Message -----
> From: Rui Paulo <[email-masked]>
> To: "[email-masked] Mailing List" <[email-masked]>
> Cc: 
> Sent: Wednesday, 10 October 2012 6:25 AM
> Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-nd-extension-headers-00.txt>
> 
>>  as Proposed Standard.  Substantive comments and statements of support for 
> advancing this document should be directed to the mailing list.  Editorial 
> suggestions can be sent to the authors.  This last call will end on 18 October 
> 2012.
> 
> 

I support.

It might be worth also mentioning Inverse ND (RFC3122), as it potentially could have created large ND packets that needed fragmentation with long lists of addresses in NAs. I've skimmed through it, and it seems to have specifically not done so (multiple neighbor advertisements are sent if the address list is too long for a single NA), although it uses the term "message" rather than "packet". I don't seem to be able to find an absolute statement that says "message" = packet, so a misinterpretation could be that a single "message" could be built and then fragmented into multiple packets for transmission.

Regards,
Mark.