Re: I-D Action:draft-ietf-6man-exthdr-01.txt

Suresh Krishnan <suresh.krishnan@ericsson.com> Wed, 22 December 2010 05:31 UTC

Return-Path: <suresh.krishnan@ericsson.com>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C8973A6997 for <ipv6@core3.amsl.com>; Tue, 21 Dec 2010 21:31:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.568
X-Spam-Level:
X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hT79X1t5tHa for <ipv6@core3.amsl.com>; Tue, 21 Dec 2010 21:31:09 -0800 (PST)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 448CF3A698C for <ipv6@ietf.org>; Tue, 21 Dec 2010 21:31:07 -0800 (PST)
Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id oBM65nHD028754; Wed, 22 Dec 2010 00:05:50 -0600
Received: from [142.133.10.113] (147.117.20.213) by eusaamw0712.eamcs.ericsson.se (147.117.20.182) with Microsoft SMTP Server id 8.2.234.1; Wed, 22 Dec 2010 00:32:57 -0500
Message-ID: <4D118D6C.10106@ericsson.com>
Date: Wed, 22 Dec 2010 00:32:28 -0500
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20101027)
MIME-Version: 1.0
To: Tony Li <tony.li@tony.li>
Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt
References: <20101217234501.11691.81147.idtracker@localhost> <AANLkTi=Lr_4zOd=-DrAxic_t_o0MvyOoWPYmiktZZod2@mail.gmail.com> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <AA183326-2E70-4A23-83A7-9F96131ADFF4@tony.li> <4D113364.3050105@ericsson.com> <34F3EC7B-6EFA-4C0F-8773-DD3A3F2F76BB@tony.li>
In-Reply-To: <34F3EC7B-6EFA-4C0F-8773-DD3A3F2F76BB@tony.li>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Dec 2010 05:31:10 -0000

Hi Tony,

On 10-12-21 06:30 PM, Tony Li wrote:
> Hi Suresh,
> 
>>> It does seem helpful and useful to propose that future new extension headers be TLV encoded.  While it seems obvious from 2460 that this was the intent, I cannot find that explicitly stated anywhere.  I would support this draft simply stating that and no more.  This should therefore be a one sentence document (minus the boilerplate ;-).  
>> And that is exactly what this draft started out as (a standard format for new extension headers to follow).
>>
>> http://tools.ietf.org/html/draft-krishnan-ipv6-exthdr-00
> 
> 
> That's not _exactly_ true.  See section 3 of that document.  I think that that section would create issues.
> 
> 
>> The idea of burning one protocol number right now was suggested by the WG in order to limit further exhaustion of the protocol number space. Would it be more acceptable to you, if we do not ask for an IANA allocation for a protocol number at this point, and wait till the first "Specific Type" request comes up?
> 
> 
> The typical approach to code point exhaustion is to reserve one code point value within the space for future expansion.  Fortunately, that has already been done.  Value 255 has already been reserved.  This is both necessary and sufficient.
> 
> 
>>> It seems like a generic extension will simply create a security issue, with a new covert channel for IPv6.
>>> The document seems to mandate the internal format of future extensions, above and beyond TLV encoding.  This seems overly restrictive and insufficiently motivated.
>> Which fields are you specifically concerned about?
> 
> 
> I'm referring to the Specific Type and Header Options fields.

We will come back with a proposal to resolve the issues that you, Ran 
and Fernando raised.

Thanks
Suresh