Subject: Consensus call on adopting draft-krishnan-ipv6-exthdr

From: Brian Haberman <[email-masked]>
Date: Mon, 26 Apr 2010 08:17:11 -0400

All,
      The 6MAN chairs would like feedback from the working group on 
adopting draft-krishnan-ipv6-exthdr as a WG item.  Please send your 
comments/opinions to the mailing list (or the chairs) by May 7, 2010.

Regards,
Brian & Bob

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 26 Apr 2010 07:37:16 -0700

Hi,

I support the effort.

Thanks,
Vishwas

On Mon, Apr 26, 2010 at 5:17 AM, Brian Haberman
<[email-masked]> wrote:
> All,
>     The 6MAN chairs would like feedback from the working group on adopting
> draft-krishnan-ipv6-exthdr as a WG item.  Please send your comments/opinions
> to the mailing list (or the chairs) by May 7, 2010.
>
> Regards,
> Brian & Bob
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Apr 2010 17:02:04 +0200

Le 26/04/2010 14:17, Brian Haberman a écrit :
> draft-krishnan-ipv6-exthdr as a WG item. Please send your

Comments...
> 3. Backward Compatibility
>
>
>    The scheme proposed in this document is not backward compatible with
>    all the currently defined IPv6 extension headers.  It only applies to
>    newly defined extension headers.  Specifically, the following
>    extension headers predate this document and do not follow the format
>    proposed in this document.
>
>    o  IPv6 Hop-by-Hop Options Header
>    o  IPv6 Routing Header
>    o  IPv6 Fragment Header
>    o  IPv6 Destination Options Header

And AH and ESP?

Alex

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Mon, 26 Apr 2010 12:44:45 -0500

I support this effort as I think it will "future proof" extension
headers as far as stateful firewalls are concerned - but what I'm
interested in is finding out how much demand for new extension headers
there is out there - and what those new extension headers would be.

- Wes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Haberman
Sent: Monday, April 26, 2010 8:17 AM
To: IPv6 WG Mailing List
Subject: Consensus call on adopting draft-krishnan-ipv6-exthdr

All,

Regards,
Brian & Bob

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 26 Apr 2010 13:57:22 -0400

Hi Alex,

>>    o  IPv6 Destination Options Header

AH & ESP are not considered as IPv6 extension headers and they are 
considered as payload as far as IPv6 is concerned.

Thanks
Suresh

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 26 Apr 2010 11:20:34 -0700

Hi Suresh,

This brings the interesting issue, how do I know if the unknown inner
header is payload vs Extension header?

Thanks,
Vishwas

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 26 Apr 2010 14:18:29 -0400

Hi Vishwas,
   The idea is that all new IPv6 extension headers will use the same 
Next Header value (allocated in this draft). Anything else will be a 
payload/upper layer protocol.

i.e. An unknown extension header will have a known "Next Header" value 
but an unknown "Specific Type" inside the GIEH and an unknown upper 
layer protocol will have an unknown "Next Header" value.

Thanks
Suresh

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 26 Apr 2010 11:37:21 -0700

Hi Suresh,

> i.e. An unknown extension header will have a known "Next Header" value but
> an unknown "Specific Type" inside the GIEH and an unknown upper layer
> protocol will have an unknown "Next Header" value.

This need not be the case. What if two new headers are defined. Also
if it is a payload how do we make sure the payload first byte does not
match a known "Next header" field.

I think the first case you need to define is some values of extension
headers (x to y). That will solve all your issues.

Thanks,
Vishwas

On Mon, Apr 26, 2010 at 11:18 AM, Suresh Krishnan
<[email-masked]> wrote:
> Hi Vishwas,
>  The idea is that all new IPv6 extension headers will use the same Next
> Header value (allocated in this draft). Anything else will be a
> i.e. An unknown extension header will have a known "Next Header" value but
> an unknown "Specific Type" inside the GIEH and an unknown upper layer
> protocol will have an unknown "Next Header" value.
>
> Thanks
> Suresh
>

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 26 Apr 2010 15:07:36 -0400

Hi Jeremy,

On 10-04-26 02:07 PM, Duncan, Jeremy wrote:
> Pretty sure all extension headers are considered payload of the IPv6 header.  Check out RFC 2460.  It says ESP and AH are there..

As you stated above RFC2460 does talk about the AH and ESP, but the AH 
spec itself contains the following text.

"In the IPv6 context, AH is viewed as an end-to-end payload, and thus
  should appear after hop-by-hop, routing, and fragmentation extension
  headers."

I do not have any strong opinions on whether to include AH and ESP in 
the Backward compatibility section. I can change the text to add AH and 
ESP if there is working group consensus to do so.

Thanks
Suresh

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Apr 2010 22:37:52 +0200

Le 26/04/2010 19:57, Suresh Krishnan a écrit :
>>> All, The 6MAN chairs would like feedback from the working group
>>> on adopting draft-krishnan-ipv6-exthdr as a WG item. Please send
>>>  your comments/opinions to the mailing list (or the chairs) by
>>> May 7, 2010.
>>
>> Comments...
>>> The scheme proposed in this document is not backward compatible
>>> with all the currently defined IPv6 extension headers. It only
>>> applies to newly defined extension headers. Specifically, the
>>> following extension headers predate this document and do not
>>> follow the format proposed in this document.
>>>
>>> o IPv6 Hop-by-Hop Options Header o IPv6 Routing Header o IPv6
>>> Fragment Header o IPv6 Destination Options Header
>>
>> And AH and ESP?
>

Related... DO (and others maybe) may sometimes appear before some times
after AH.  Will the krishnan-exthdr appear before and some times after AH?

In addition, how would one specify which fields of the
yet-to-be-specified extension header using the krishnan-exthdr rules, be
covered by AH? (and which fields not covered by AH).

Or is this draft mainly intended for firewalls which would ignore AH?

I am curious, is there some other draft planning to use krishnan-exthdr?
Somebody plans on using it?

Thanks,

Alex

> Thanks Suresh

---

From: Stig Venaas <[email-masked]>
Date: Mon, 26 Apr 2010 13:52:13 -0700

> there is out there - and what those new extension headers would be.

I can agree that it's good to check demand, but I think it is good to
do the "future proofing" anyway. Things can then be implemented today
and work correctly (as in ignoring unknown headers and still finding
the transport) if new headers are introduced later.

An alternative approach could perhaps be to set aside a small range of
protocol values for future extension headers?

Stig

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 26 Apr 2010 14:13:31 -0700

Hi Stig,

> protocol values for future extension headers?
I do not think it is an alternative approach. The values tell its an
extension header (and are required look at my previous mail) and
follows the format defined, but the structure still needs to be
defined.

Thanks,
Vishwas

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Apr 2010 09:42:15 +1200

>>    o  IPv6 Destination Options Header

Same question about the shim6 extension header defined in RFC 5533.
In one mode it's a payload extension header, but not in the case
of a shim6 control message, if I understand correctly.

   Brian C

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 26 Apr 2010 19:21:20 -0400

Hi Brian/Alex,

> of a shim6 control message, if I understand correctly.

Whether it is an extension header currently defined or an upper-layer 
protocol (current or future), this format does not apply. It is a 
generic mechanism that future extension headers could voluntarily use to 
become middlebox friendly and to save protocol numbers.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 26 Apr 2010 19:24:49 -0400

Hi Vishwas,

> follows the format defined, but the structure still needs to be

I think Stig means reserving a few IP protocol values for extension 
headers. It is certainly an alternative approach (the scheme proposed in 
the draft uses only one protocol number and demultiplexes extension 
headers based on the "Specific Type" field)

Thanks
Suresh

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 26 Apr 2010 16:51:52 -0700

Hi Suresh,

If you read the mail below (which I sent earlier in the day) this is
what I had said too. Just reserving values will not do, we need to
also define the structure otherwise it will not work.

Thanks,
Vishwas
On Mon, Apr 26, 2010 at 4:24 PM, Suresh Krishnan
<[email-masked]> wrote:
> I think Stig means reserving a few IP protocol values for extension headers.
> It is certainly an alternative approach (the scheme proposed in the draft
> uses only one protocol number and demultiplexes extension headers based on
> the "Specific Type" field)
>
> Thanks
> Suresh
>

---

From: Shane Amante <[email-masked]>
Date: Mon, 26 Apr 2010 21:54:37 -0600

On Apr 26, 2010, at 06:17 MDT, Brian Haberman wrote:
> All,
>     The 6MAN chairs would like feedback from the working group on adopting draft-krishnan-ipv6-exthdr as a WG item.  Please send your comments/opinions to the mailing list (or the chairs) by May 7, 2010.

I support this draft being adopted as a WG draft.

-shane

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Apr 2010 16:01:30 +1200

> become middlebox friendly and to save protocol numbers.

Understood, but I am wondering whether the shim6 extension header needs
to be added to the above list of exceptions.

   Brian

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 27 Apr 2010 11:09:47 -0400

Hi Brian,

> to be added to the above list of exceptions.

I am fine with adding the shim6,AH, and ESP into the exception list. Do 
you think that this exception list is useful?

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 27 Apr 2010 12:38:06 -0400

Hi Vishwas,
   Maybe I am misunderstanding you, but I do not see the problem here. I 
will try to explain how two different extension headers can be defined 
without conflicting with a payload protocol type.

Imagine the GIEH has been allocated the IP protocol value of 144. Let's 
also imagine that two new extension headers are defined using the GIEH. 
The first header is allocated the specific type 6 and the second is 
allocated the specific type 21. A TCP packet containing both these 
headers will look like this

V= Version
NH= Next Header
HEL= Hdr Ext Len
ST= Specific Type

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  V=6  | Traffic Class |           Flow Label                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |    NH=144     |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                         Source Address                        +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Destination Address                      +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    NH=144     |     HEL=5     |     ST=8      |               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
|                                                               |
.                                                               .
.      45 bytes of type 6 extension header specific data        .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    NH=6       |     HEL=3     |     ST=21     |               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
|                                                               |
.                                                               .
.      29 bytes of type 21 extension header specific data       .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        TCP Header                             |
.                                                               .
.                                                               .

Do you see any problems with this?

Cheers
Suresh

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 27 Apr 2010 09:56:58 -0700

Hi Suresh,

Yes I see a big problem with this.  Am I missing the point altogather?

As we have no defined ranges for Extension Headers, what if the value
144 is given to a new transport/ other protocol header.

As we do not know if 144 is a new tranport header or IPv6 extension
header, we do not know how to parse the Extension header. If we parsed
it as an Extension Header how would we know that we are not parsing it
wrongly. This is perfect remedy for crashes and havoc in the system.

What am I missing? BTW, the diagram below the NH field of the first
extension header does not look right to me.

Thanks,
Vishwas

On Tue, Apr 27, 2010 at 9:38 AM, Suresh Krishnan
<[email-masked]> wrote:
> Hi Vishwas,
>  Maybe I am misunderstanding you, but I do not see the problem here. I will
> try to explain how two different extension headers can be defined without
> conflicting with a payload protocol type.
>
> Imagine the GIEH has been allocated the IP protocol value of 144. Let's also
> imagine that two new extension headers are defined using the GIEH. The first
> header is allocated the specific type 6 and the second is allocated the
> specific type 21. A TCP packet containing both these headers will look like
> this
>
> V= Version
> NH= Next Header
> HEL= Hdr Ext Len
> ST= Specific Type
>
>>> but
>>> headers.

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 27 Apr 2010 12:59:48 -0400

Hi Vishwas,

> 144 is given to a new transport/ other protocol header.

It will not be given out to anything else. See below.

> What am I missing? 

I think you are missing the part that the value (144 in my example) will 
be allocated by IANA specifically for the GIEH (as per the IANA 
considerations section of the draft) and will not be available for 
allocation to transport protocols.

> BTW, the diagram below the NH field of the first

Why? It just states that there is another generic extension header that 
follows.

Thanks
Suresh

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 27 Apr 2010 10:21:54 -0700

Hi Suresh,

You are right.  Thanks for clarifying this, I didnt read the draft
carefully enough.

I guess I missed the part that the types inside the header will not be
the same as outside. That is why I was thinking we needed to allocate
a range.

That said is there a limit on the number of extension headers that can
be added for each sub-type/ total number of Extension headers.

How do we make sure that the TCP Header and the IP header are in the
same Fragment? (otherwise the entire 5-tuple inspection requires
packet reassembly which is not what we want)

Thanks,
Vishwas

On Tue, Apr 27, 2010 at 9:59 AM, Suresh Krishnan
<[email-masked]> wrote:
> I think you are missing the part that the value (144 in my example) will be
> allocated by IANA specifically for the GIEH (as per the IANA considerations
> section of the draft) and will not be available for allocation to transport
> protocols.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Apr 2010 09:33:38 +1200

> you think that this exception list is useful?

I think it is useful guidance for implementors, if and only if
it's complete. If anything is missed out, it could be misleading.

    Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 28 Apr 2010 14:15:13 +0200

Le 27/04/2010 23:33, Brian E Carpenter a écrit :
>>>> Whether it is an extension header currently defined or an
>>>> upper-layer protocol (current or future), this format does not
>>>> apply. It is a generic mechanism that future extension headers
>>>> could voluntarily use to become middlebox friendly and to save
>>>> protocol numbers.
>>>
>>> Understood, but I am wondering whether the shim6 extension header
>>> needs to be added to the above list of exceptions.
>>
>> I am fine with adding the shim6,AH, and ESP into the exception
>> list. Do you think that this exception list is useful?
>
> I think it is useful guidance for implementors, if and only if it's
> complete. If anything is missed out, it could be misleading.

I agree too.

Often during protocol design one needs to have all similar things
in one place, instead of spread out in various RFCs, e.g.: list of users
of HbH, list of possible flow label uses, etc.

It's good to list in one place all existing Extension Headers: we're
thus sure to not leave out some exception when trying to generalize into
exthdr.

Alex

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

---

From: Rémi Després <[email-masked]>
Date: Thu, 29 Apr 2010 11:24:54 +0200

Brian, Bob,

>     The 6MAN chairs would like feedback from the working group on adopting draft-krishnan-ipv6-exthdr as a WG item.  Please send your comments/opinions to the mailing list (or the chairs) by May 7,…

+1 for draft-krishnan-ipv6-exthdr to become a WG item.

Rergards,
RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 29 Apr 2010 11:33:02 +0200

Le 26 avr. 2010 à 22:52, Stig Venaas a écrit :

> I can agree that it's good to check demand,

No urgency IMHO.

> but I think it is good to
> do the "future proofing" anyway.

Urgent.

> Things can then be implemented today

Yes.

> protocol values for future extension headers?

Not as good, by far.
So, I hope we can quickly endorse draft-krishnan-ipv6-exthdr, and satisfy the identified need once and for all.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 29 Apr 2010 11:54:24 +0200

Hi Suresh,

Le 27 avr. 2010 à 17:09, Suresh Krishnan a écrit :

> ...
> I am fine with adding the shim6,AH, and ESP into the exception list. Do you think that this exception list is useful?

Indeed:
- The GIEH new extension header is for *future* extensions.
- It is too late for "existing" ones;
- The endorsed list of these "existing" extensions is essential for codes that look for transport headers to be really able to do it.

Cheers,
RD

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Thu, 29 Apr 2010 19:53:21 +0200

>comments/opinions to the mailing list (or the chairs) by May 7, 2010.

+1, to adopt this draft as a working item!

a) this draft solves _real_ world problems. The current
   mechanism is broken by design and anything from being future safe!
	 Think about IPv6 capable devices with a lifetime of a decade like SOHO
	 routers, etcetera.

Current linux implementation:

net/ipv6/exthdrs_core.c:ipv6_ext_hdr()

     return ( (nexthdr == NEXTHDR_HOP)   ||
          (nexthdr == NEXTHDR_ROUTING)   ||
          (nexthdr == NEXTHDR_FRAGMENT)  ||
          (nexthdr == NEXTHDR_AUTH)  ||
          (nexthdr == NEXTHDR_NONE)  ||
          (nexthdr == NEXTHDR_DEST) );

b) the final standard should update RFC2460 and it should mentioned that
   this extension header should be used.

HGN

PS: why does the document do not mentioned the authentication extention
header?

-- 
Hagen Paul Pfeifer <[email-masked]>  ||  http://jauu.net/
Telephone: +49 174 5455209           ||  Key Id: 0x98350C22
Key Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22
Always in motion, the future is.

---

From: james woodyatt <[email-masked]>
Date: Thu, 29 Apr 2010 12:16:40 -0600

>     The 6MAN chairs would like feedback from the working group on adopting draft-krishnan-ipv6-exthdr as a WG item.  Please send your comments/opinions to the mailing list (or the chairs) by May 7,…

I don't object to 6MAN taking up this draft as a working group item, but I'd like to add to my comments on an earlier thread.

I wrote: 

>> I'd say there are two changes we should make to Section 6, IANA Considerations, in the next revision:
>> 
>> + instruct IANA to reserve GIEH sub-type values for experimental purposes and cite RFC 3692.
>> 
>> + instruct IANA to require a *separate* IETF standards action to allow [new] IPv6 extension headers to be numbered from the assigned protocol number database *before* assigning any such numbers to a new extension header.

If 6MAN takes this as a work item, then I think it will be a pointless exercise without considering the second item in my list.

When this document goes to publication, we want to make it very clear that we're setting a standard that *all* new extension headers will use the GIEH format unless and until we ever set a new standard that allows for exceptions to be published.  If we don't do that, then the value of having the GIEH is lost.

I may have some other improvements to propose once this becomes a working group draft.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 29 Apr 2010 19:37:24 -0400

Hi Hagen,

> PS: why does the document do not mentioned the authentication extention

Others (Alex/Brian/Remi) have also pointed this out. It is an omission 
and will be fixed in the next version of the draft.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 29 Apr 2010 19:38:31 -0400

Hi James,

> When this document goes to publication, we want to make it very clear that we're setting a standard that *all* new extension headers will use the GIEH format unless and until we ever set a new stan…

Fully agree. Do you think such restriction needs to be mentioned in the 
IANA considerations section of this draft?

Cheers
Suresh

---

From: james woodyatt <[email-masked]>
Date: Thu, 29 Apr 2010 17:49:04 -0600

On Apr 29, 2010, at 17:38, Suresh Krishnan wrote:
> 
> Fully agree. Do you think such restriction needs to be mentioned in the IANA considerations section of this draft?

I think 6MAN should consider it.  I'd be interested to see reasons to think that making such an instruction to IANA would be a bad idea.

---

From: Rémi Després <[email-masked]>
Date: Fri, 30 Apr 2010 09:50:16 +0200

> When this document goes to publication, we want to make it very clear that we're setting a standard that *all* new extension headers will use the GIEH format unless and until we ever set a new stan…

Agreed: making this explicit rather than just implicit is IMHO a useful improvement.

Regards,
RD