Hi Pekka,
Operational input: when discussing the use of RFC4941
(privacy) addresses with our LAN/workstation admins, it
seemed as if there would be great benefit from being able to
specify an RFC3484 rule which would in essence say:
do not use privacy addresses when communicating inside
Hi Joel,
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On
Behalf Of Joel M. Halpern
Sent: Tuesday, January 04, 2011 12:26 PM
To: Fernando Gont
Cc: ipv6@ietf.org
Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt
Then what about if we forget
For clarity, in terms of the pieces of your original note:
I consider (a), specifying the format at least to the level of requiring
TLV encoding, to be a good idea.
I do not see any particular advantage in (b), allocating a code point,
but I can live with it if the WG wants it.
And (c),
On 05 Jan 2011, at 05:12 , Suresh Krishnan wrote:
I'm up for it :-). In fact I already suggested the meat in
http://www.ietf.org/mail-archive/web/ipv6/current/msg13207.html
RFC2460 allows the use of both extension headers and destination options in
order to encode optional destination
Earlier, Manav wrote:
Assume you are the end host that wants to prioritize certain packets
or wants to implement Access control lists (ACLs). In the absence
of this extension a router cannot apply ACLs as it will never know how
to parse the packet in case it comes across an unknown
On 2011-01-06 02:15, RJ Atkinson wrote:
...
A) Prohibiting new IPv6 Extension Headers outright,
as Joel has repeatedly suggested. This removes the
narrow case where RFC-2460 allows Extension Headers,
so the I-D would be an Update to RFC-2460.
My reaction is that this is going too
On 05 Jan 2011, at 15:15 , Brian E Carpenter wrote:
On 2011-01-06 02:15, RJ Atkinson wrote:
...
A) Prohibiting new IPv6 Extension Headers outright,
as Joel has repeatedly suggested. This removes the
narrow case where RFC-2460 allows Extension Headers,
so the I-D would be an Update
