denial of service attack using prefixes with very small Valid = Lifetimes

From dmudric@avaya.com Tue Feb 2 09:38:10 2010 Return-Path: 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 C08BE3A690F for ; Tue, 2 Feb 2010 09:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 RNg9oOksBz7Q for ; Tue, 2 Feb 2010 09:38:10 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id B7CBA3A68AA for ; Tue, 2 Feb 2010 09:38:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,391,1262581200"; d="scan'208,217";a="2131379" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 02 Feb 2010 12:38:47 -0500 X-IronPort-AV: E=Sophos;i="4.49,391,1262581200"; d="scan'208,217";a="441810528" Received: from unknown (HELO zcars04f.nortel.com) ([47.129.242.57]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Feb 2010 12:38:46 -0500 Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o12HcPL06053 for ; Tue, 2 Feb 2010 17:38:25 GMT Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o12HcNe07379 for ; Tue, 2 Feb 2010 17:38:23 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAA42E.62380CD2" Subject: denial of service attack using prefixes with very small Valid Lifetimes Date: Tue, 2 Feb 2010 12:37:24 -0500 Message-ID: <90243C8A881F8D419D855264D9636F3A0390BDA0@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: denial of service attack using prefixes with very small Valid Lifetimes Thread-Index: AcqkLmGe3OCfgPbjQyqSPDd4WyWuyQ== From: "Dusan Mudric" To: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 17:38:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAA42E.62380CD2 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi, Is there a mechanism to protect against a denial of service attack using = prefixes with very small Valid Lifetimes? RFC 2462, section 5.5.3 e) = talks about it but does not seam to cover the scenario where: 1) A user defines a small Preferred and Valid Lifetimes (i.e., 10sec = and 15sec), and 2) The initial Router Advertisement message has very small Preferred = and Valid Lifetimes for a Prefix, and=20 3) The received Lifetime is equal to Stored Lifetime. With the small lifetime, address expires quickly and is created soon = after. Applications using this address go up and down periodically and = get into trouble. Have this issue already been addressed? Regards,=20 Du=B9an Mudri=E6=20 Software Architect Avaya=20 ------_=_NextPart_001_01CAA42E.62380CD2 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable denial of service attack using prefixes with very small Valid = Lifetimes

Hi,

Is there = a mechanism to protect against a denial of service attack using prefixes with very small = Valid Lifetimes? RFC 2462, section 5.5.3 = e) talks about it but does not seam to cover the scenario = where:

1) A user defines a small Preferred and Valid Lifetimes (i.e., 10sec and 15sec), = and

2) The initial Router Advertisement message has very small Preferred = and Valid Lifetimes for a Prefix, and

3) The received Lifetime is equal to = Stored Lifetime.

With the small lifetime, address = expires quickly and is created soon after. Applications using this = address go up and down periodically and get into trouble.

Have this issue already been = addressed?

Regards,

Du=B9an Mudri=E6

Software Architect

Avaya

------_=_NextPart_001_01CAA42E.62380CD2-- From brian.e.carpenter@gmail.com Tue Feb 2 12:26:29 2010 Return-Path: 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 3B3393A6B6A; Tue, 2 Feb 2010 12:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599] 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 6hqnwyiqrgfG; Tue, 2 Feb 2010 12:26:27 -0800 (PST) Received: from mail-pz0-f183.google.com (mail-pz0-f183.google.com [209.85.222.183]) by core3.amsl.com (Postfix) with ESMTP id C4EDE3A6B66; Tue, 2 Feb 2010 12:26:27 -0800 (PST) Received: by pzk13 with SMTP id 13so574518pzk.32 for ; Tue, 02 Feb 2010 12:27:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=5DP/U4N6VMN0uRDeq2A0HoaGYnWU5lCmmkpmyInN2OA=; b=MJWT2s1dqgibl76pGgz6MZ5HLYeaiJl0W7pz/LD//vg+dksGKeMmXZp5f0oyWjpc2T gSCTpdeDDwA/464LBknywEXdg4eGFQmfNHgBQLqL2y3PV2tyWKP524YwBDKZn8Pdn3s0 m0JfGoheQ6acZDy435NkbqkYCMZyxtjAcmyAc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=hW9J++TcCXQTNmy5n7DB9cgS795KMyheMFZ3jFekMgXmvMplsXSmxyxQiiz5l0Vhie jcT1lowZzdxGf57O8b4VF40ZdR8uBhTUz10orAB7O12ZsSVxqDkhz6PBmzg+76yf9oAG qMOqaZ83xm0g5BS9Miq618H4jwvwrGKsiRiMI= Received: by 10.142.5.21 with SMTP id 21mr802346wfe.137.1265142424369; Tue, 02 Feb 2010 12:27:04 -0800 (PST) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 20sm3056261pzk.9.2010.02.02.12.27.01 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Feb 2010 12:27:03 -0800 (PST) Message-ID: <4B688A92.7000100@gmail.com> Date: Wed, 03 Feb 2010 09:26:58 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Black_David@emc.com Subject: Re: [Gen-art] Gen-ART review of draft-ietf-6man-text-addr-representation-04 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man-chairs@tools.ietf.org, akawamucho@mesh.ad.jp, ipv6@ietf.org, iesg@ietf.org, gen-art@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 20:26:29 -0000 David, The problem is that we cannot make this a required format. Like it or not, there is a range of ways to represent an IPv6 address in text form, and has been for many years. 2001:DEAD:BEEF:: and 2001:deAd:BEeF:: are the same address. The draft is very precise on this point: The recommendation in this document SHOULD be followed by systems when generating an address to represent as text, but all implementations MUST accept any legitimate [RFC4291] format. This is the only approach which is consistent with history. Making that SHOULD into a MUST would be simply unrealistic. But I really don't understand your objection to this as a standards track document. It's a complete, if simple, normative specification. (It could also have been a BCP, imho, but the WG preferred standards track.) I don't see any particular need to provide pseudocode; it wouldn't change the normative content. It certainly wouldn't do any harm. Regards Brian Carpenter On 2010-02-03 03:36, Black_David@emc.com wrote: > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-6man-text-addr-representation-04 > Reviewer: David L. Black > Review Date: February 2, 2010 > IESG Telechat date: February 4, 2010 > > Summary: > This draft is on the right track, but has open issues, described > in the review. > > Comments: > The draft provides recommendations for a canonical format for IPv6 > addresses. > > The open issue is that the draft only provides recommendations, and > does not tightly specify a canonical format. A tight specification > of a canonical format would include at least one (and preferably > both) of: > - An algorithm to test whether an IPv6 text address > is in the canonical format > - An algorithm to convert an IPv6 text address into canonical > form. > Code or pseudo-code should be used, and note that the latter item > subsumes the former (a canonicalization algorithm makes no changes to > input that's already in the canonical format). In the absence of > these elements, I'm not convinced that the draft defines an > interoperable standard that solves the problem. > > This document is a good start - I think it's a fine requirements > document that would be appropriate to publish as an Informational RFC, > but I believe that more work is needed to produce a standards-track RFC > that specifies an interoperable representation. If this document > is published in its current form, it should be edited slightly to > make it clear that it is only a requirements document. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art > From brian.e.carpenter@gmail.com Tue Feb 2 15:03:01 2010 Return-Path: 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 B50093A6BA1; Tue, 2 Feb 2010 15:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.17 X-Spam-Level: X-Spam-Status: No, score=-3.17 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599] 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 rFjbZtc0XNPa; Tue, 2 Feb 2010 15:02:55 -0800 (PST) Received: from mail-pz0-f183.google.com (mail-pz0-f183.google.com [209.85.222.183]) by core3.amsl.com (Postfix) with ESMTP id 462793A6B91; Tue, 2 Feb 2010 15:02:55 -0800 (PST) Received: by pzk13 with SMTP id 13so771711pzk.32 for ; Tue, 02 Feb 2010 15:03:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=LzAtvvEA6ggLSIc5D7kCdtKoKZqnbHbQdZf2OIrNjRQ=; b=lwxwCT2cc6cG5mWIbvgAUKe58NbAxTGKQKrNMg6KP2ozf449wcyA9Sgis6uXI5D+Zo N7lSG27sYh9ZXjP0V8p7wbxPjBY+Yni/mMe48l5XzB8n9OJ2/S2cOm5H4NKHvlsYCO21 hrcXTtsv5mnlIJ08jCH9gahf7nRtcG9UNI7FQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=Bdf9BvPFOfH0Ztx5eQgRvuOuRcbr7X9/fRTeeDkZ6K1b8UB4YadgThhYT6uGeQKBkG M+8S3NpSlBfqfwjeFAEo+b4dCRwspqhxpRQWlcfqz6YfPNq/kDD9N7Kz1iFIzKWF2+Pv qDL50PKT6s1TsEdLqd65nXKH8Md8BwDE5k5rc= Received: by 10.141.187.13 with SMTP id o13mr4500868rvp.28.1265151810984; Tue, 02 Feb 2010 15:03:30 -0800 (PST) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 20sm3200225pzk.13.2010.02.02.15.03.28 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Feb 2010 15:03:30 -0800 (PST) Message-ID: <4B68AF3E.4070909@gmail.com> Date: Wed, 03 Feb 2010 12:03:26 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Black_David@emc.com Subject: Re: [Gen-art] Gen-ART reviewof draft-ietf-6man-text-addr-representation-04 References: <4B688A92.7000100@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, gen-art@ietf.org, iesg@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 23:03:01 -0000 OK, we do disagree about that ;-) On 2010-02-03 10:23, Black_David@emc.com wrote: > The concern is not whether it is required (MUST) vs. recommended > (SHOULD), but rather than the canonical form is not sufficiently > specified. Towards that end we disagree on the level of need for > pseudocode. > > Thanks, > --David > > >> -----Original Message----- >> From: gen-art-bounces@ietf.org [mailto:gen-art-bounces@ietf.org] On > Behalf Of Brian E Carpenter >> Sent: Tuesday, February 02, 2010 3:27 PM >> To: Black, David >> Cc: 6man-chairs@tools.ietf.org; akawamucho@mesh.ad.jp; ipv6@ietf.org; > kawashimam@necat.nec.co.jp; >> iesg@ietf.org; gen-art@ietf.org >> Subject: Re: [Gen-art] Gen-ART reviewof > draft-ietf-6man-text-addr-representation-04 >> David, >> >> The problem is that we cannot make this a required format. Like it or >> not, there is a range of ways to represent an IPv6 address in text >> form, and has been for many years. 2001:DEAD:BEEF:: and > 2001:deAd:BEeF:: >> are the same address. >> >> The draft is very precise on this point: >> >> The >> recommendation in this document SHOULD be followed by systems when >> generating an address to represent as text, but all implementations >> MUST accept any legitimate [RFC4291] format. >> >> This is the only approach which is consistent with history. Making >> that SHOULD into a MUST would be simply unrealistic. But I really >> don't understand your objection to this as a standards track document. >> It's a complete, if simple, normative specification. (It could also >> have been a BCP, imho, but the WG preferred standards track.) >> >> I don't see any particular need to provide pseudocode; it wouldn't >> change the normative content. It certainly wouldn't do any harm. >> >> Regards >> Brian Carpenter >> >> On 2010-02-03 03:36, Black_David@emc.com wrote: >>> I have been selected as the General Area Review Team (Gen-ART) >>> reviewer for this draft (for background on Gen-ART, please see >>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>> >>> Please wait for direction from your document shepherd >>> or AD before posting a new version of the draft. >>> >>> Document: draft-ietf-6man-text-addr-representation-04 >>> Reviewer: David L. Black >>> Review Date: February 2, 2010 >>> IESG Telechat date: February 4, 2010 >>> >>> Summary: >>> This draft is on the right track, but has open issues, described >>> in the review. >>> >>> Comments: >>> The draft provides recommendations for a canonical format for IPv6 >>> addresses. >>> >>> The open issue is that the draft only provides recommendations, and >>> does not tightly specify a canonical format. A tight specification >>> of a canonical format would include at least one (and preferably >>> both) of: >>> - An algorithm to test whether an IPv6 text address >>> is in the canonical format >>> - An algorithm to convert an IPv6 text address into canonical >>> form. >>> Code or pseudo-code should be used, and note that the latter item >>> subsumes the former (a canonicalization algorithm makes no changes > to >>> input that's already in the canonical format). In the absence of >>> these elements, I'm not convinced that the draft defines an >>> interoperable standard that solves the problem. >>> >>> This document is a good start - I think it's a fine requirements >>> document that would be appropriate to publish as an Informational > RFC, >>> but I believe that more work is needed to produce a standards-track > RFC >>> that specifies an interoperable representation. If this document >>> is published in its current form, it should be edited slightly to >>> make it clear that it is only a requirements document. >>> >>> Thanks, >>> --David >>> ---------------------------------------------------- >>> David L. Black, Distinguished Engineer >>> EMC Corporation, 176 South St., Hopkinton, MA 01748 >>> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >>> black_david@emc.com Mobile: +1 (978) 394-7754 >>> ---------------------------------------------------- >>> >>> >>> _______________________________________________ >>> Gen-art mailing list >>> Gen-art@ietf.org >>> https://www.ietf.org/mailman/listinfo/gen-art >>> >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art > > From kawamucho@mesh.ad.jp Tue Feb 2 17:12:03 2010 Return-Path: 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 CDF723A63EC; Tue, 2 Feb 2010 17:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 MbPXheJqVJXd; Tue, 2 Feb 2010 17:12:01 -0800 (PST) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by core3.amsl.com (Postfix) with ESMTP id 236663A6782; Tue, 2 Feb 2010 17:12:00 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.192]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id o131CZRi019925; Wed, 3 Feb 2010 10:12:35 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id o131CZt18390; Wed, 3 Feb 2010 10:12:35 +0900 (JST) Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id o131CZ5A003182; Wed, 3 Feb 2010 10:12:35 +0900 (JST) Received: from bsac29088.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o131CZ1D027842; Wed, 3 Feb 2010 10:12:35 +0900 Received: from mail.sys.biglobe.nec.co.jp (bgsx5626.sys.biglobe.nec.co.jp [10.18.151.10]) by bsac29088.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o131CZGm024748; Wed, 3 Feb 2010 10:12:35 +0900 Received: from [127.0.0.1] (edonet065.sys.biglobe.nec.co.jp [10.19.137.65]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o131CZAT012049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Feb 2010 10:12:35 +0900 Message-ID: <4B68CD81.8050803@mesh.ad.jp> Date: Wed, 03 Feb 2010 10:12:33 +0900 From: Seiichi Kawamura User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [Gen-art] Gen-ART reviewof draft-ietf-6man-text-addr-representation-04 References: <4B688A92.7000100@gmail.com> <4B68AF3E.4070909@gmail.com> In-Reply-To: <4B68AF3E.4070909@gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, gen-art@ietf.org, Black_David@emc.com, iesg@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 01:12:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. I see the telechat is scheduled for tomorrow. I will wait. Regards, Seiichi Brian E Carpenter wrote: > OK, we do disagree about that ;-) > > On 2010-02-03 10:23, Black_David@emc.com wrote: >> The concern is not whether it is required (MUST) vs. recommended >> (SHOULD), but rather than the canonical form is not sufficiently >> specified. Towards that end we disagree on the level of need for >> pseudocode. >> >> Thanks, >> --David >> >> >>> -----Original Message----- >>> From: gen-art-bounces@ietf.org [mailto:gen-art-bounces@ietf.org] On >> Behalf Of Brian E Carpenter >>> Sent: Tuesday, February 02, 2010 3:27 PM >>> To: Black, David >>> Cc: 6man-chairs@tools.ietf.org; akawamucho@mesh.ad.jp; ipv6@ietf.org; >> kawashimam@necat.nec.co.jp; >>> iesg@ietf.org; gen-art@ietf.org >>> Subject: Re: [Gen-art] Gen-ART reviewof >> draft-ietf-6man-text-addr-representation-04 >>> David, >>> >>> The problem is that we cannot make this a required format. Like it or >>> not, there is a range of ways to represent an IPv6 address in text >>> form, and has been for many years. 2001:DEAD:BEEF:: and >> 2001:deAd:BEeF:: >>> are the same address. >>> >>> The draft is very precise on this point: >>> >>> The >>> recommendation in this document SHOULD be followed by systems when >>> generating an address to represent as text, but all implementations >>> MUST accept any legitimate [RFC4291] format. >>> >>> This is the only approach which is consistent with history. Making >>> that SHOULD into a MUST would be simply unrealistic. But I really >>> don't understand your objection to this as a standards track document. >>> It's a complete, if simple, normative specification. (It could also >>> have been a BCP, imho, but the WG preferred standards track.) >>> >>> I don't see any particular need to provide pseudocode; it wouldn't >>> change the normative content. It certainly wouldn't do any harm. >>> >>> Regards >>> Brian Carpenter >>> >>> On 2010-02-03 03:36, Black_David@emc.com wrote: >>>> I have been selected as the General Area Review Team (Gen-ART) >>>> reviewer for this draft (for background on Gen-ART, please see >>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>>> >>>> Please wait for direction from your document shepherd >>>> or AD before posting a new version of the draft. >>>> >>>> Document: draft-ietf-6man-text-addr-representation-04 >>>> Reviewer: David L. Black >>>> Review Date: February 2, 2010 >>>> IESG Telechat date: February 4, 2010 >>>> >>>> Summary: >>>> This draft is on the right track, but has open issues, described >>>> in the review. >>>> >>>> Comments: >>>> The draft provides recommendations for a canonical format for IPv6 >>>> addresses. >>>> >>>> The open issue is that the draft only provides recommendations, and >>>> does not tightly specify a canonical format. A tight specification >>>> of a canonical format would include at least one (and preferably >>>> both) of: >>>> - An algorithm to test whether an IPv6 text address >>>> is in the canonical format >>>> - An algorithm to convert an IPv6 text address into canonical >>>> form. >>>> Code or pseudo-code should be used, and note that the latter item >>>> subsumes the former (a canonicalization algorithm makes no changes >> to >>>> input that's already in the canonical format). In the absence of >>>> these elements, I'm not convinced that the draft defines an >>>> interoperable standard that solves the problem. >>>> >>>> This document is a good start - I think it's a fine requirements >>>> document that would be appropriate to publish as an Informational >> RFC, >>>> but I believe that more work is needed to produce a standards-track >> RFC >>>> that specifies an interoperable representation. If this document >>>> is published in its current form, it should be edited slightly to >>>> make it clear that it is only a requirements document. >>>> >>>> Thanks, >>>> --David >>>> ---------------------------------------------------- >>>> David L. Black, Distinguished Engineer >>>> EMC Corporation, 176 South St., Hopkinton, MA 01748 >>>> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >>>> black_david@emc.com Mobile: +1 (978) 394-7754 >>>> ---------------------------------------------------- >>>> >>>> >>>> _______________________________________________ >>>> Gen-art mailing list >>>> Gen-art@ietf.org >>>> https://www.ietf.org/mailman/listinfo/gen-art >>>> >>> _______________________________________________ >>> Gen-art mailing list >>> Gen-art@ietf.org >>> https://www.ietf.org/mailman/listinfo/gen-art >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAktozYEACgkQcrhTYfxyMkIq9gCeJaRRF6bBtCC3wKcDKo+iu7vD OaAAnAmK55UOrIXDSjs90TUBKTpqEdaw =WhO+ -----END PGP SIGNATURE----- From christopher.morrow@gmail.com Tue Feb 2 19:06:48 2010 Return-Path: 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 9BADB3A69E8 for ; Tue, 2 Feb 2010 19:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 1recgsIFpSl3 for ; Tue, 2 Feb 2010 19:06:47 -0800 (PST) Received: from mail-iw0-f178.google.com (mail-iw0-f178.google.com [209.85.223.178]) by core3.amsl.com (Postfix) with ESMTP id BFC003A68CB for ; Tue, 2 Feb 2010 19:06:47 -0800 (PST) Received: by iwn8 with SMTP id 8so913267iwn.13 for ; Tue, 02 Feb 2010 19:07:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3/1lwwuzTXdRaPH2yMSsAHwjBhbLk6KF7RjP1kErIM4=; b=Gttl8YkczSGy9NQCMFngVbpU7kglD1vHT8Nq08jbDk8oVi/bc3Hb/ywiU/BmoW5H0l qlDTgFnvwxdezLisUrxGr7fGX/FE7EGkRzpWuRi2cpxtvRp/uDAMRgkI3gw8tbehi/G0 zc7/Jje65SXzj3MjfLXtcBAcFxNUzl2oLF1kY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=t3TbCdbaYrsxPxTtjCpNzNtOxGoq4X89ecYaFGY836Ert0P0xxEKodI+hgSu3KPu6g IfRwyz/TL636wBkkY0XP13+lqtpkG2p4jL8SfEzBbDhyTeAIDKqi/dDhM3vpqqkbEsHD ZD/mO7fhu2r6HDv+SKhWOW9Py7g5zdyB8C240= MIME-Version: 1.0 Received: by 10.231.143.148 with SMTP id v20mr3578458ibu.14.1265166445669; Tue, 02 Feb 2010 19:07:25 -0800 (PST) In-Reply-To: <90243C8A881F8D419D855264D9636F3A0390BDA0@zcarhxm2.corp.nortel.com> References: <90243C8A881F8D419D855264D9636F3A0390BDA0@zcarhxm2.corp.nortel.com> Date: Tue, 2 Feb 2010 22:07:25 -0500 Message-ID: <75cb24521002021907g55875005h8762ba2938278dcd@mail.gmail.com> Subject: Re: denial of service attack using prefixes with very small Valid Lifetimes From: Christopher Morrow To: Dusan Mudric Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 03:06:48 -0000 2010/2/2 Dusan Mudric : > Hi, > > Is there a mechanism to protect against a denial of service attack using > prefixes with very small Valid Lifetimes? RFC 2462, section 5.5.3 e) talk= s > about it but does not seam to cover the scenario where: > > 1) A user defines a small Preferred and Valid Lifetimes (i.e., 10sec and > 15sec), and > > 2) The initial Router Advertisement message has very small Preferred and > Valid Lifetimes for a Prefix, and > > 3) The received Lifetime is equal to Stored Lifetime. This sounds like privacy addresses, only on a shorter timescale. > > With the small lifetime, address expires quickly and is created soon afte= r. > Applications using this address go up and down periodically and get into > trouble. do you mean: o attack on the router o client side changes, so the server can't block the user's IP, since it's changing 'rapidly' o server side changes, so the server has to track also dns updates such that the remote users/clients can continue to find the server reliably your problem statement is a tad vague. -chris > Have this issue already been addressed? > > Regards, > > Du=B9an Mudri=E6 > > Software Architect > > Avaya > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Feb 2 22:48:50 2010 Return-Path: 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 C09123A6870 for ; Tue, 2 Feb 2010 22:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 1F8Y+v6mw+K1 for ; Tue, 2 Feb 2010 22:48:49 -0800 (PST) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by core3.amsl.com (Postfix) with ESMTP id 86C493A6860 for ; Tue, 2 Feb 2010 22:48:49 -0800 (PST) Received: from 114-30-104-198.ip.adam.com.au ([114.30.104.198] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1NcZ3G-0000ZW-Qd; Wed, 03 Feb 2010 17:19:26 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 0D48049308; Wed, 3 Feb 2010 17:19:26 +1030 (CST) Date: Wed, 3 Feb 2010 17:19:25 +1030 From: Mark Smith To: "Dusan Mudric" Subject: Re: denial of service attack using prefixes with very small Valid Lifetimes Message-ID: <20100203171925.66ba03f9@opy.nosense.org> In-Reply-To: <90243C8A881F8D419D855264D9636F3A0390BDA0@zcarhxm2.corp.nortel.com> References: <90243C8A881F8D419D855264D9636F3A0390BDA0@zcarhxm2.corp.nortel.com> X-Mailer: Claws Mail 3.7.4 (GTK+ 2.18.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 06:48:51 -0000 Hi Dusan, On Tue, 2 Feb 2010 12:37:24 -0500 "Dusan Mudric" wrote: > Hi, >=20 > Is there a mechanism to protect against a denial of service attack using = prefixes with very small Valid Lifetimes? RFC 2462, section 5.5.3 e) talks = about it but does not seam to cover the scenario where: >=20 > 1) A user defines a small Preferred and Valid Lifetimes (i.e., 10sec an= d 15sec), and > 2) The initial Router Advertisement message has very small Preferred an= d Valid Lifetimes for a Prefix, and=20 > 3) The received Lifetime is equal to Stored Lifetime. >=20 > With the small lifetime, address expires quickly and is created soon afte= r. Applications using this address go up and down periodically and get into= trouble. >=20 > Have this issue already been addressed? >=20 I'm not sure if it has specifically. In general thought, the only people who should be configuring a router with these types of parameters would be trusted network administrators on trusted routers. If an untrusted network administrator is able to change the parameters on a trusted router, then I think the root problem isn't that they can maliciously configure parameters of the protocols the trusted router talks, but that they've got administrative access to the router itself. Better access control e.g. stronger passwords is the best method to prevent this. If it's an untrusted router announcing these parameters, then=20 http://tools.ietf.org/id/draft-ietf-v6ops-ra-guard-04.txt is addressing that threat. Regards, Mark. > Regards,=20 >=20 > Du=B9an Mudri=E6=20 >=20 > Software Architect > Avaya=20 >=20 >=20 >=20 >=20 From suresh.krishnan@ericsson.com Wed Feb 3 07:38:12 2010 Return-Path: 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 A0A2F28C0D9 for ; Wed, 3 Feb 2010 07:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 l3QM4Swa-8et for ; Wed, 3 Feb 2010 07:38:11 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id C2CFA3A6C50 for ; Wed, 3 Feb 2010 07:38:11 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id o13Fe21C023474; Wed, 3 Feb 2010 09:40:02 -0600 Received: from [142.133.10.113] (147.117.20.212) by eusaamw0712.eamcs.ericsson.se (147.117.20.182) with Microsoft SMTP Server id 8.1.375.2; Wed, 3 Feb 2010 10:38:52 -0500 Message-ID: <4B69979A.1030606@ericsson.com> Date: Wed, 3 Feb 2010 10:34:50 -0500 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Dusan Mudric Subject: Re: denial of service attack using prefixes with very small Valid Lifetimes References: <90243C8A881F8D419D855264D9636F3A0390BDA0@zcarhxm2.corp.nortel.com> In-Reply-To: <90243C8A881F8D419D855264D9636F3A0390BDA0@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 15:38:12 -0000 Hi Dusan, It is not clear to me where the denial of service occurs. This is just a configuration error on the router (to have such small lifetimes). NOTE: RFC2462 has been obsoleted by RFC4862. Cheers Suresh On 10-02-02 12:37 PM, Dusan Mudric wrote: > Hi, > > Is there a mechanism to protect against a denial of service attack using > prefixes with very small Valid Lifetimes? RFC 2462, section 5.5.3 e) > talks about it but does not seam to cover the scenario where: > > 1) A user defines a small Preferred and Valid Lifetimes > (i.e., 10sec and 15sec), and > > 2) The initial Router Advertisement message has very small > Preferred and Valid Lifetimes for a Prefix, and > > 3) The received Lifetime is equal to Stored Lifetime. > > With the small lifetime, address expires quickly and is created soon > after. Applications using this address go up and down periodically and > get into trouble. > > Have this issue already been addressed? > > Regards, > > Du�an Mudric' > > > Software Architect > > Avaya > > From Black_David@emc.com Tue Feb 2 06:44:33 2010 Return-Path: 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 24E133A6941; Tue, 2 Feb 2010 06:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 XfosS456HU7c; Tue, 2 Feb 2010 06:44:32 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id CF80D3A6864; Tue, 2 Feb 2010 06:44:31 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id o12Ej9l2005700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Feb 2010 09:45:09 -0500 Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 2 Feb 2010 09:44:58 -0500 Received: from corpussmtp1.corp.emc.com (corpussmtp1.corp.emc.com [128.221.166.44]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o12EitJr023728; Tue, 2 Feb 2010 09:44:55 -0500 Received: from CORPUSMX80B.corp.emc.com ([10.254.89.201]) by corpussmtp1.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Feb 2010 09:36:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Gen-ART review of draft-ietf-6man-text-addr-representation-04 Date: Tue, 2 Feb 2010 09:36:41 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART review of draft-ietf-6man-text-addr-representation-04 Thread-Index: AcqkFSJdpatitI5NTLmCm4cathb4Nw== X-Priority: 1 priority: Urgent Importance: high From: To: , , X-OriginalArrivalTime: 02 Feb 2010 14:36:42.0513 (UTC) FILETIME=[23308010:01CAA415] X-EMM-EM: Active X-Mailman-Approved-At: Wed, 03 Feb 2010 09:52:40 -0800 Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, Black_David@emc.com, iesg@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 14:44:33 -0000 I have been selected as the General Area Review Team (Gen-ART)=20 reviewer for this draft (for background on Gen-ART, please see=20 http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd=20 or AD before posting a new version of the draft.=20 Document: draft-ietf-6man-text-addr-representation-04 Reviewer: David L. Black Review Date: February 2, 2010 IESG Telechat date: February 4, 2010 Summary: This draft is on the right track, but has open issues, described in the review. Comments: The draft provides recommendations for a canonical format for IPv6 addresses. The open issue is that the draft only provides recommendations, and does not tightly specify a canonical format. A tight specification of a canonical format would include at least one (and preferably both) of: - An algorithm to test whether an IPv6 text address is in the canonical format - An algorithm to convert an IPv6 text address into canonical form. Code or pseudo-code should be used, and note that the latter item subsumes the former (a canonicalization algorithm makes no changes to input that's already in the canonical format). In the absence of these elements, I'm not convinced that the draft defines an interoperable standard that solves the problem. This document is a good start - I think it's a fine requirements document that would be appropriate to publish as an Informational RFC, but I believe that more work is needed to produce a standards-track RFC that specifies an interoperable representation. If this document is published in its current form, it should be edited slightly to make it clear that it is only a requirements document. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) = 293-7786 black_david@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From Black_David@emc.com Tue Feb 2 13:23:00 2010 Return-Path: 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 5B4F83A6B85; Tue, 2 Feb 2010 13:23:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 zzgdNNBtsGlO; Tue, 2 Feb 2010 13:22:59 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id DBD733A6996; Tue, 2 Feb 2010 13:22:58 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id o12LNa0e004577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Feb 2010 16:23:36 -0500 Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 2 Feb 2010 16:23:26 -0500 Received: from corpussmtp5.corp.emc.com (corpussmtp5.corp.emc.com [128.221.166.229]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o12LNO19017049; Tue, 2 Feb 2010 16:23:25 -0500 Received: from CORPUSMX80B.corp.emc.com ([10.254.89.201]) by corpussmtp5.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Feb 2010 16:23:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Gen-art] Gen-ART reviewof draft-ietf-6man-text-addr-representation-04 Date: Tue, 2 Feb 2010 16:23:24 -0500 Message-ID: In-Reply-To: <4B688A92.7000100@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Gen-art] Gen-ART reviewof draft-ietf-6man-text-addr-representation-04 Thread-Index: AcqkRjSSSyfM81UPR8KcSGg7j40PFQAB08jA References: <4B688A92.7000100@gmail.com> From: To: X-OriginalArrivalTime: 02 Feb 2010 21:23:23.0917 (UTC) FILETIME=[F38F43D0:01CAA44D] X-EMM-EM: Active X-Mailman-Approved-At: Wed, 03 Feb 2010 09:52:40 -0800 Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, gen-art@ietf.org, iesg@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 21:23:00 -0000 The concern is not whether it is required (MUST) vs. recommended (SHOULD), but rather than the canonical form is not sufficiently specified. Towards that end we disagree on the level of need for pseudocode. Thanks, --David > -----Original Message----- > From: gen-art-bounces@ietf.org [mailto:gen-art-bounces@ietf.org] On Behalf Of Brian E Carpenter > Sent: Tuesday, February 02, 2010 3:27 PM > To: Black, David > Cc: 6man-chairs@tools.ietf.org; akawamucho@mesh.ad.jp; ipv6@ietf.org; kawashimam@necat.nec.co.jp; > iesg@ietf.org; gen-art@ietf.org > Subject: Re: [Gen-art] Gen-ART reviewof draft-ietf-6man-text-addr-representation-04 >=20 > David, >=20 > The problem is that we cannot make this a required format. Like it or > not, there is a range of ways to represent an IPv6 address in text > form, and has been for many years. 2001:DEAD:BEEF:: and 2001:deAd:BEeF:: > are the same address. >=20 > The draft is very precise on this point: >=20 > The > recommendation in this document SHOULD be followed by systems when > generating an address to represent as text, but all implementations > MUST accept any legitimate [RFC4291] format. >=20 > This is the only approach which is consistent with history. Making > that SHOULD into a MUST would be simply unrealistic. But I really > don't understand your objection to this as a standards track document. > It's a complete, if simple, normative specification. (It could also > have been a BCP, imho, but the WG preferred standards track.) >=20 > I don't see any particular need to provide pseudocode; it wouldn't > change the normative content. It certainly wouldn't do any harm. >=20 > Regards > Brian Carpenter >=20 > On 2010-02-03 03:36, Black_David@emc.com wrote: > > I have been selected as the General Area Review Team (Gen-ART) > > reviewer for this draft (for background on Gen-ART, please see > > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > > > Please wait for direction from your document shepherd > > or AD before posting a new version of the draft. > > > > Document: draft-ietf-6man-text-addr-representation-04 > > Reviewer: David L. Black > > Review Date: February 2, 2010 > > IESG Telechat date: February 4, 2010 > > > > Summary: > > This draft is on the right track, but has open issues, described > > in the review. > > > > Comments: > > The draft provides recommendations for a canonical format for IPv6 > > addresses. > > > > The open issue is that the draft only provides recommendations, and > > does not tightly specify a canonical format. A tight specification > > of a canonical format would include at least one (and preferably > > both) of: > > - An algorithm to test whether an IPv6 text address > > is in the canonical format > > - An algorithm to convert an IPv6 text address into canonical > > form. > > Code or pseudo-code should be used, and note that the latter item > > subsumes the former (a canonicalization algorithm makes no changes to > > input that's already in the canonical format). In the absence of > > these elements, I'm not convinced that the draft defines an > > interoperable standard that solves the problem. > > > > This document is a good start - I think it's a fine requirements > > document that would be appropriate to publish as an Informational RFC, > > but I believe that more work is needed to produce a standards-track RFC > > that specifies an interoperable representation. If this document > > is published in its current form, it should be edited slightly to > > make it clear that it is only a requirements document. > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > > > > _______________________________________________ > > Gen-art mailing list > > Gen-art@ietf.org > > https://www.ietf.org/mailman/listinfo/gen-art > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From bob.hinden@gmail.com Wed Feb 3 10:23:35 2010 Return-Path: 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 2122928C193 for ; Wed, 3 Feb 2010 10:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 ARx1acK3UcaW for ; Wed, 3 Feb 2010 10:23:34 -0800 (PST) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 264923A6CA4 for ; Wed, 3 Feb 2010 10:23:33 -0800 (PST) Received: by ewy28 with SMTP id 28so1761751ewy.28 for ; Wed, 03 Feb 2010 10:24:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=1MJsQBDLDRhcldk2j7Zcivpuv98/DBzTPALi0iwW+YY=; b=AB3AQSXYstGkAGrXMcQxF4DyXXd82jPulsciQlcz9NM4KhL07zkAKhSEWHPWNJnJbV VMGFcIboXnjvHEwDQHBgRRloi7/maUIZvwK6zRTHDqofWNqP99PMhLvQVS9dpCbAnBhR Q3kjWx6m/RZ7TxM76m/V011nMmo6sIN0BGA00= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=cO2GSiBYKPzHpcZR63eqlGhjDzyXkFvZvdPstQtRQYFp6QGCY9fwVVby+yEq4iehWy 4rklcqh07iQujIfxtc3SOmP1UEMcZrbZI6Z9PUKtoRfL80Em4K7vBFRRSOdFghFPFE0d EmpVHvzEyLdbFnMCkFcCCNOm1Dh0UGmb36Cv4= Received: by 10.213.75.134 with SMTP id y6mr7592196ebj.48.1265221450337; Wed, 03 Feb 2010 10:24:10 -0800 (PST) Received: from ?10.0.0.27? (h-66-166-21-1.snvacaid.static.covad.net [66.166.21.1]) by mx.google.com with ESMTPS id 15sm93886ewy.4.2010.02.03.10.24.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Feb 2010 10:24:09 -0800 (PST) Subject: Re: denial of service attack using prefixes with very small Valid Lifetimes Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: Bob Hinden In-Reply-To: <4B69979A.1030606@ericsson.com> Date: Wed, 3 Feb 2010 10:24:05 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3E6D854C-E1F5-4F85-8C5A-470572871D53@gmail.com> References: <90243C8A881F8D419D855264D9636F3A0390BDA0@zcarhxm2.corp.nortel.com> <4B69979A.1030606@ericsson.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.1077) Cc: Dusan Mudric , "ipv6@ietf.org" , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 18:23:35 -0000 On Feb 3, 2010, at 7:34 AM, Suresh Krishnan wrote: > Hi Dusan, > It is not clear to me where the denial of service occurs. This is = just a configuration error on the router (to have such small lifetimes). That is my thought as well. =20 Bob >=20 > NOTE: RFC2462 has been obsoleted by RFC4862. >=20 > Cheers > Suresh >=20 > On 10-02-02 12:37 PM, Dusan Mudric wrote: >> Hi, >> Is there a mechanism to protect against a denial of service attack = using prefixes with very small Valid Lifetimes? RFC 2462, section 5.5.3 = e) talks about it but does not seam to cover the scenario where: >> 1) A user defines a small Preferred and Valid Lifetimes >> (i.e., 10sec and 15sec), and >> 2) The initial Router Advertisement message has very small >> Preferred and Valid Lifetimes for a Prefix, and >> 3) The received Lifetime is equal to Stored Lifetime. >> With the small lifetime, address expires quickly and is created soon = after. Applications using this address go up and down periodically and = get into trouble. >> Have this issue already been addressed? >> Regards, >> Du=9Aan Mudric' >> Software Architect >> Avaya >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From jari.arkko@piuha.net Fri Feb 5 04:52:54 2010 Return-Path: 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 8760628C115; Fri, 5 Feb 2010 04:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599] 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 9jgfGV2lY764; Fri, 5 Feb 2010 04:52:53 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 9FF813A6D6C; Fri, 5 Feb 2010 04:52:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B5A642D289; Fri, 5 Feb 2010 14:53:39 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrLFKbQZpAjv; Fri, 5 Feb 2010 14:53:39 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 365DB2D275; Fri, 5 Feb 2010 14:53:39 +0200 (EET) Message-ID: <4B6C14D2.60304@piuha.net> Date: Fri, 05 Feb 2010 14:53:38 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: draft-ietf-6man-text-addr-representation@tools.ietf.org, IETF IPv6 Mailing List Subject: next steps with 6man-text-addr-representation Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IESG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 12:52:54 -0000 This draft was on the IESG review yesterday, and did not get approved due to a number of Discusses from the other ADs. There's a number of small details that we can talk about separately, but I wanted to talk to the working group about the high level issues. Generally speaking the reviewers were surprised about the lack of preciseness in the definition of the canonical form. This had to do with the IPv4-embedded addresses, the specification style and lack of MUST keywords, and so on. I think everyone believed the draft as currently written will already improve things, but many reviewers felt that it could have been much stricter. The reviewers were also wondering about the role of the draft, will it affect everything or just other specifications that decide to adopt the new format. I explained the situation with the IPv4-embedded addresses -- this is a design tradeoff where we can either nail down everything now and not have a nice textual representation in some cases, or we can leave some flexibility. We've already had this discussion in the working group, and I believe we keep the current approach in the draft. However, we need to add the rationale to the draft so that future readers are not asking the same questions as our reviewers did now. Then we talked about the strictness. I explained that this is largely a specification style issue, and in the real world there will always be old code that doesn't produce the canonical form, and that we hope that this RFC will convince all new code to do the right thing. However, we came up with the following proposal to make the specification stricter: - Use RFC 2119 language and MUST. Implementations conforming to this specification MUST ... - Provide a reference to the currently defined WKPs - In the section that talks about ports, please make sure that for URIs everyone MUST follow RFC 3986, and for the rest, the default can be again RFC 3986. The current language leaves everything open, even for URIs. - There's a part about reducing longest sequence of 0s -- it would be great if we could point to some publicly available code that already does this, as an informational reference to implementors - We will keep the specification on the Standards Track, i.e., publish it as a Proposed Standard - This specification Updates RFC 4291 Would these changes be acceptable to the working group? Jari From marka@isc.org Fri Feb 5 05:16:22 2010 Return-Path: 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 032FD28C0D0; Fri, 5 Feb 2010 05:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 udCDO-aNIzR2; Fri, 5 Feb 2010 05:16:20 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id 63E393A6EF7; Fri, 5 Feb 2010 05:16:20 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 7D5A0E601C; Fri, 5 Feb 2010 13:17:08 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o15DH5Rh065500; Sat, 6 Feb 2010 00:17:05 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201002051317.o15DH5Rh065500@drugs.dv.isc.org> To: Jari Arkko From: Mark Andrews References: <4B6C14D2.60304@piuha.net> Subject: Re: next steps with 6man-text-addr-representation In-reply-to: Your message of "Fri, 05 Feb 2010 14:53:38 +0200." <4B6C14D2.60304@piuha.net> Date: Sat, 06 Feb 2010 00:17:05 +1100 Sender: marka@isc.org Cc: draft-ietf-6man-text-addr-representation@tools.ietf.org, IETF IPv6 Mailing List , IESG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 13:16:22 -0000 In message <4B6C14D2.60304@piuha.net>, Jari Arkko writes: > This draft was on the IESG review yesterday, and did not get approved > due to a number of Discusses from the other ADs. > > There's a number of small details that we can talk about separately, but > I wanted to talk to the working group about the high level issues. > Generally speaking the reviewers were surprised about the lack of > preciseness in the definition of the canonical form. This had to do with > the IPv4-embedded addresses, the specification style and lack of MUST > keywords, and so on. I think everyone believed the draft as currently > written will already improve things, but many reviewers felt that it > could have been much stricter. The reviewers were also wondering about > the role of the draft, will it affect everything or just other > specifications that decide to adopt the new format. > > I explained the situation with the IPv4-embedded addresses -- this is a > design tradeoff where we can either nail down everything now and not > have a nice textual representation in some cases, or we can leave some > flexibility. We've already had this discussion in the working group, and > I believe we keep the current approach in the draft. However, we need to > add the rationale to the draft so that future readers are not asking the > same questions as our reviewers did now. > > Then we talked about the strictness. I explained that this is largely a > specification style issue, and in the real world there will always be > old code that doesn't produce the canonical form, and that we hope that > this RFC will convince all new code to do the right thing. However, we > came up with the following proposal to make the specification stricter: > > - Use RFC 2119 language and MUST. Implementations conforming to this > specification MUST ... > - Provide a reference to the currently defined WKPs > - In the section that talks about ports, please make sure that for URIs > everyone MUST follow RFC 3986, and for the rest, the default can be > again RFC 3986. The current language leaves everything open, even for URIs. > - There's a part about reducing longest sequence of 0s -- it would be > great if we could point to some publicly available code that already > does this, as an informational reference to implementors ISC's inet_ntop() was released in 1996 as part of BIND 8. It's also in BIND 9. > - We will keep the specification on the Standards Track, i.e., publish > it as a Proposed Standard > - This specification Updates RFC 4291 > > Would these changes be acceptable to the working group? > > Jari > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jari.arkko@piuha.net Fri Feb 5 05:31:27 2010 Return-Path: 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 85B1028C12E; Fri, 5 Feb 2010 05:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599] 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 aIpNpbrv7Vmr; Fri, 5 Feb 2010 05:31:26 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id B246E28C11D; Fri, 5 Feb 2010 05:31:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id AB49D2D289; Fri, 5 Feb 2010 15:32:16 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cB+DYPmexHzS; Fri, 5 Feb 2010 15:32:16 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 2B2342D275; Fri, 5 Feb 2010 15:32:16 +0200 (EET) Message-ID: <4B6C1DDF.70904@piuha.net> Date: Fri, 05 Feb 2010 15:32:15 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Mark Andrews Subject: Re: next steps with 6man-text-addr-representation References: <4B6C14D2.60304@piuha.net> <201002051317.o15DH5Rh065500@drugs.dv.isc.org> In-Reply-To: <201002051317.o15DH5Rh065500@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-6man-text-addr-representation@tools.ietf.org, IETF IPv6 Mailing List , IESG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 13:31:27 -0000 Mark, > ISC's inet_ntop() was released in 1996 as part of BIND 8. It's also in > BIND 9. > Ah, great! Thanks for the information. Jari From bob.hinden@gmail.com Fri Feb 5 12:47:10 2010 Return-Path: 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 957E63A68AC; Fri, 5 Feb 2010 12:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 qbH+VRtEcijS; Fri, 5 Feb 2010 12:47:09 -0800 (PST) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 42AA228C0F1; Fri, 5 Feb 2010 12:47:09 -0800 (PST) Received: by ewy28 with SMTP id 28so455338ewy.28 for ; Fri, 05 Feb 2010 12:47:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=XXOahDoHIXRq3N54PxK/T7McAsNXQvUPpsIQwA1hjPg=; b=p/OgXvZGqQF64NOgHUtRanwge2NmEdNDlDZiL1dMqwD+IX8jqrkouWTBO6yctk8RCw PbMKzm3eDEcj47MOtxHnLEapSCfTI6gmhOjtSBAZnTof9EtaxH2Ob/72JxkCwnJ+g0t/ z2iuTBct9lHVn9hTFQ0D5VgcTXT16ZNJ5jCd4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=eUiK8dUSaS0kgirzN9d2l7ddGg32E7CC6vdp/gOvW1YQMckwhFMaX8LeHjABTfIhvh yPQruqaFTXeEnsVY1RLz67UEUSbqs3sMVl0+aoWd7EJ7tSh8qMn7h7IeEH5UZdc1m9cw UUd4/XCQMMyDqsGL9PSOjAmNOlpkiK+e7P3OE= Received: by 10.213.42.205 with SMTP id t13mr1017453ebe.4.1265402875904; Fri, 05 Feb 2010 12:47:55 -0800 (PST) Received: from ?209.97.124.223? ([209.97.124.223]) by mx.google.com with ESMTPS id 16sm1240790ewy.10.2010.02.05.12.47.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 05 Feb 2010 12:47:55 -0800 (PST) Subject: Re: next steps with 6man-text-addr-representation Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <4B6C14D2.60304@piuha.net> Date: Fri, 5 Feb 2010 12:47:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0C32BEB8-EE9B-40A9-A3E7-253F498A6C20@gmail.com> References: <4B6C14D2.60304@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1077) Cc: draft-ietf-6man-text-addr-representation@tools.ietf.org, Bob Hinden , IESG , IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 20:47:10 -0000 Jari, > Then we talked about the strictness. I explained that this is largely = a specification style issue, and in the real world there will always be = old code that doesn't produce the canonical form, and that we hope that = this RFC will convince all new code to do the right thing. However, we = came up with the following proposal to make the specification stricter: >=20 > - Use RFC 2119 language and MUST. Implementations conforming to this = specification MUST ... > - Provide a reference to the currently defined WKPs > - In the section that talks about ports, please make sure that for = URIs everyone MUST follow RFC 3986, and for the rest, the default can be = again RFC 3986. The current language leaves everything open, even for = URIs. > - There's a part about reducing longest sequence of 0s -- it would be = great if we could point to some publicly available code that already = does this, as an informational reference to implementors > - We will keep the specification on the Standards Track, i.e., publish = it as a Proposed Standard > - This specification Updates RFC 4291 >=20 > Would these changes be acceptable to the working group? [No hats on] I was thinking about this over the past few days after reading the IESG = comments and a discussion with Brian Haberman. My personal take is that = we lost sight of the original goal while trying to meet the broad = requirements of the different variants of embedded addresses. I was thinking that we should have a strict canonical form along the = line of what is proposed in Section 8. This format SHOULD always be = used when an IPv6 address is saved to a file or log as text (as opposed = to binary). The canonical format would not support any of the embedded = formats. Everything would look like: 2001:db8:0:0:1:22::1 2001:db8:0:0:1::1 2001:db8:0:11:222:3333:c000:0201 Tools could be built that would allow alternative ways to display the = addresses in the file. For example in the second case above, it could = be displayed as: 2001:db8:0:11:222:3333:192.0.2.1 All operations used to compare and search against entries in the file = would performed against the canonical format. A search tool could allow = an address to be entered in an embedded format (or any format defined in = RFC4291), but it would convert the address to the canonical format = before the search is performed. This is similar to the way something a spread sheet deals with dates and = times. The underlying data does not change if the user decides to = change the format it is displayed. Or this is the way that I think = tools like tcpdump deal with saved packet traces. It gives the user = control over how the data is displayed, but the data in the file is in a = general format. In this approach, a specific tool would always work to show the user = consistent address formats and avoid the problems enumerated in the = draft. For example, if a tool knew how to detect and show IPv6 = addresses with embedded IPv4 addresses, it would show everything that = way. If the tool didn't it would still provide the user a consistent = view of the addresses. I think this is the overall intent of this = draft. I think this would be a better approach and allow us to solve the = problem originally as intended when the w.g. took this work on. I would appreciate your and the w.g.'s comments. Thanks, Bob From brian.e.carpenter@gmail.com Fri Feb 5 13:03:53 2010 Return-Path: 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 A9AEA3A6E35; Fri, 5 Feb 2010 13:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599] 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 J6P+QWpjyzXd; Fri, 5 Feb 2010 13:03:52 -0800 (PST) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by core3.amsl.com (Postfix) with ESMTP id 2C71E3A6819; Fri, 5 Feb 2010 13:03:52 -0800 (PST) Received: by fxm26 with SMTP id 26so2644176fxm.13 for ; Fri, 05 Feb 2010 13:04:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=SlQGq6M5BnON2Pn+63DNspDD5JdguZ9kJcM3tjS2kp0=; b=LyIaZu3x/jAi/UgpdFZxwZc9yTEC2GvMNRO6Umpmtf0dp8kjneO/CTUXTlHUGwClFD PeDhq6QGO0c+Jo35K33wmX3YMrLdF9zNZnb/jPE2g7IRbR06A+RKb1Z1/N1uFmPaaOHD TZ/WR5atOxL9kZgh1wx7MxR08QXmBBcte1640= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=Nkmu5avLOxDmQVgaDjqi+/2zTFlKaCrAtnKdGmxMe0mCBZ7rvENi1QeBdg0V5UQrOG 40iKJHwtGVZV6mXBCovU2V2cYqQpcpcZNE0JMOcGtu3czAK788uEIEmwQl/l+afJdfog uvp1AX42T31+wplOW/YThGxpkLAXuZNz651RM= Received: by 10.223.77.66 with SMTP id f2mr3622970fak.84.1265403879989; Fri, 05 Feb 2010 13:04:39 -0800 (PST) Received: from ?10.1.1.5? ([121.98.142.15]) by mx.google.com with ESMTPS id p9sm2947205fkb.44.2010.02.05.13.04.36 (version=SSLv3 cipher=RC4-MD5); Fri, 05 Feb 2010 13:04:39 -0800 (PST) Message-ID: <4B6C87E0.7040101@gmail.com> Date: Sat, 06 Feb 2010 10:04:32 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jari Arkko Subject: Re: next steps with 6man-text-addr-representation References: <4B6C14D2.60304@piuha.net> In-Reply-To: <4B6C14D2.60304@piuha.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-6man-text-addr-representation@tools.ietf.org, 6man , IESG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 21:03:53 -0000 [repeating with the CC's this time] On 2010-02-06 01:53, Jari Arkko wrote: ... > - Use RFC 2119 language and MUST. Implementations conforming to this > specification MUST ... No real objection, but its impact of this change in the real world will be nil IMHO. > - Provide a reference to the currently defined WKPs > - In the section that talks about ports, please make sure that for URIs > everyone MUST follow RFC 3986, and for the rest, the default can be > again RFC 3986. The current language leaves everything open, even for URIs. We have to phrase this rather carefully. There is valid normative ABNF for the RFC 4291 representation in RFC 3986, but it does not generate only the proposed canonical representation. It allows leading zeroes, for example, and allows zeroes instead of ::. Also, I just came across something "interesting". RFC 3986 cites RFC 2234. In the latter, we find HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" Unfortunately, that means that the URI format (and dependencies such as SIP) don't allow lower case hex. That is inconsistent with the current draft. Oops. [Note to self - this also messes up draft-ietf-sip-ipv6-abnf-fix-04, of which I'm a co-author.] > - There's a part about reducing longest sequence of 0s -- it would be > great if we could point to some publicly available code that already > does this, as an informational reference to implementors Seichi has some code http://tools.bgp4.jp/IPv6canonical/IPv6canonical.txt > - We will keep the specification on the Standards Track, i.e., publish > it as a Proposed Standard > - This specification Updates RFC 4291 In that case we need to state explicitly that lower case hex is allowed; 4291 only shows upper case examples. > > Would these changes be acceptable to the working group? > > Jari > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From brian@innovationslab.net Fri Feb 5 13:11:42 2010 Return-Path: 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 2676028C0EC; Fri, 5 Feb 2010 13:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Lb3-PcwCqMvl; Fri, 5 Feb 2010 13:11:32 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by core3.amsl.com (Postfix) with ESMTP id 4007B3A67B4; Fri, 5 Feb 2010 13:11:31 -0800 (PST) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 1192A88271; Fri, 5 Feb 2010 13:12:22 -0800 (PST) Received: from DeathValley.local (c-69-255-98-109.hsd1.md.comcast.net [69.255.98.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 23F921369360; Fri, 5 Feb 2010 13:12:19 -0800 (PST) Message-ID: <4B6C8970.8070406@innovationslab.net> Date: Fri, 05 Feb 2010 16:11:12 -0500 From: Brian Haberman User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: iesg-secretary@ietf.org, Jari Arkko , "Ralph Droms (rdroms)" Subject: Request To Advance: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bob Hinden , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 21:11:42 -0000 Jari & Ralph, On behalf of the 6MAN WG, the chairs request the advancement of: Title : IPv6 Subnet Model: the Relationship between Links and Subnet Prefixes Author(s) : H. Singh, et al. Filename : draft-ietf-6man-ipv6-subnet-model-07.txt Pages : 13 Date : 2009-12-23 as a proposed standard. A 6MAN WG Last Call completed on October 14, 2009 and this version addresses all issues raised. Regards, Brian & Bob 6MAN co-chairs From ietf-ipng@m.gmane.org Fri Feb 5 13:14:26 2010 Return-Path: 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 CC1173A6C8A for ; Fri, 5 Feb 2010 13:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 Q67I8aDQVaIs for ; Fri, 5 Feb 2010 13:14:22 -0800 (PST) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by core3.amsl.com (Postfix) with ESMTP id 19B193A6855 for ; Fri, 5 Feb 2010 13:14:21 -0800 (PST) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1NdVW9-0006rG-4D for ipv6@ietf.org; Fri, 05 Feb 2010 22:15:09 +0100 Received: from 109-184-133-218.dynamic.mts-nn.ru ([109.184.133.218]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Feb 2010 22:15:09 +0100 Received: from DXDragon by 109-184-133-218.dynamic.mts-nn.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Feb 2010 22:15:09 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ipv6@ietf.org From: =?utf-8?B?0KDQvtC80LDQvSDQlNC+0L3Rh9C10L3QutC+?= Subject: Re: next steps with 6man-text-addr-representation Date: Sat, 06 Feb 2010 00:14:39 +0300 Lines: 17 Message-ID: References: <4B6C14D2.60304@piuha.net> <4B6C87E0.7040101@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 109-184-133-218.dynamic.mts-nn.ru User-Agent: Opera Mail/10.10 (Win32) Sender: news X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 21:14:27 -0000 Brian E Carpenter писал в своём письме Sat, 06 Feb 2010 00:04:32 +0300: > Also, I just came across something "interesting". RFC 3986 cites RFC > 2234. > In the latter, we find > HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" > Unfortunately, that means that the URI format (and dependencies such > as SIP) don't allow lower case hex. That is inconsistent with > the current draft. Oops. > > [Note to self - this also messes up draft-ietf-sip-ipv6-abnf-fix-04, > of which I'm a co-author.] ABNF string literals are case-insensitive. Roman. From brian.e.carpenter@gmail.com Fri Feb 5 14:36:42 2010 Return-Path: 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 5F39C3A6E56; Fri, 5 Feb 2010 14:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.769 X-Spam-Level: X-Spam-Status: No, score=-2.769 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599] 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 3TJ+3U9Z1K56; Fri, 5 Feb 2010 14:36:41 -0800 (PST) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by core3.amsl.com (Postfix) with ESMTP id 3DE8C3A69A0; Fri, 5 Feb 2010 14:36:40 -0800 (PST) Received: by fxm26 with SMTP id 26so2742265fxm.13 for ; Fri, 05 Feb 2010 14:37:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=QNy9PbAJPPG5oXEqkaNMjtu8qyEL+2E6kaupRG0hAvo=; b=dAnuCBgsV4u7heQ5XZ/YgXJaVCB+zvCaNramQsmAS6FnbhM1uo9mNifNNXkGSE/U0a F/RR/OThir5s+IEe8gwwcp02kJN/GM1mAtiK/uDevCv2H6dev180tRQ7oXE+4Ip/qY3w TYNkJq5PghFEThwB+NpsD8BlMDGLYh4WZmvII= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=OUepomZTObDN50urBE9mviFV9/oK8nJgzS9bz6vO6ckY12LMYb5g1wJOz3VloYrIpT aYynwhJSB3n/+Nrjgzt7RpqXDlz3aMbQ6nyFUDNw0NdjTMSmKW4GBSc+KCOCRYqEBfj4 rD0JHOWQQa3clcKrmoOn/Hn9UXD/zkPVPiZ+E= Received: by 10.223.26.216 with SMTP id f24mr49845fac.20.1265409449294; Fri, 05 Feb 2010 14:37:29 -0800 (PST) Received: from ?10.1.1.5? ([121.98.142.15]) by mx.google.com with ESMTPS id 21sm3055635fkx.25.2010.02.05.14.37.24 (version=SSLv3 cipher=RC4-MD5); Fri, 05 Feb 2010 14:37:28 -0800 (PST) Message-ID: <4B6C9DA0.9010904@gmail.com> Date: Sat, 06 Feb 2010 11:37:20 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: next steps with 6man-text-addr-representation References: <4B6C14D2.60304@piuha.net> <4B6C87E0.7040101@gmail.com> <4B6C88F2.8040406@isode.com> In-Reply-To: <4B6C88F2.8040406@isode.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-6man-text-addr-representation@tools.ietf.org, IESG , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 22:36:42 -0000 On 2010-02-06 10:09, Alexey Melnikov wrote: > Hi Brian, ... >> Also, I just came across something "interesting". RFC 3986 cites RFC >> 2234. >> In the latter, we find >> HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" >> Unfortunately, that means that the URI format (and dependencies such >> as SIP) don't allow lower case hex. That is inconsistent with >> the current draft. Oops. >> >> > Actually no, all quoted strings in ABNF are case-insensitive. So "A" > matches both "A" and "a", etc. Oh, OK, that is fine for conformance of course, but leaves things open when you are talking about generating strings. If we want the new recommendation to be a MUST, we may have to consider wording to make it clear how widely it applies. Many existing specs may be affected implicitly. Brian From brian.e.carpenter@gmail.com Fri Feb 5 14:50:25 2010 Return-Path: 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 24D343A6E62; Fri, 5 Feb 2010 14:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.754 X-Spam-Level: X-Spam-Status: No, score=-2.754 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599] 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 RGEZXA+o-Xm9; Fri, 5 Feb 2010 14:50:24 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id C5BF03A67B2; Fri, 5 Feb 2010 14:50:23 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so263544eya.5 for ; Fri, 05 Feb 2010 14:51:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Hu3S7ziya7VkWIQOr7Wp3NW4n1IDGx37YE40tFHAvAc=; b=fB7EJxyYYCifnXqGO1L3hZ3jUes6uNUHcoU/uD/IBXsSIc8g81dCEElr707T2OPjTS p+Z0nrX3YqogtWgwSf6HBTX8WrlwBgIAfs+yssq8IVFRw2R2nfEWp73+Z12UNR4Y67s+ krLYPHTSuqJV6qdzF2vUYsPa6tGvul5S+Hjhg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=xzNdLWxXFnW4fH7yWhjGaA2bsOVvhZC4fMl7rS6JP1B0z+qSnRyUCZGlSPZHlNliMU ofNp1uv90nYGliZlhbMU+GtfSs0wy/TM0k7KXIhPna3cWItAmBENc3j7FqVJcSvAmPNF 9iH53jK1UERsoUhvBis+akFB/8YagoEcxRttI= Received: by 10.213.0.147 with SMTP id 19mr1777970ebb.34.1265410272470; Fri, 05 Feb 2010 14:51:12 -0800 (PST) Received: from ?10.1.1.5? ([121.98.142.15]) by mx.google.com with ESMTPS id 14sm1321730ewy.3.2010.02.05.14.51.08 (version=SSLv3 cipher=RC4-MD5); Fri, 05 Feb 2010 14:51:11 -0800 (PST) Message-ID: <4B6CA0D7.1010705@gmail.com> Date: Sat, 06 Feb 2010 11:51:03 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Bob Hinden Subject: Re: next steps with 6man-text-addr-representation References: <4B6C14D2.60304@piuha.net> <0C32BEB8-EE9B-40A9-A3E7-253F498A6C20@gmail.com> In-Reply-To: <0C32BEB8-EE9B-40A9-A3E7-253F498A6C20@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-6man-text-addr-representation@tools.ietf.org, IESG , IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 22:50:25 -0000 Bob, On 2010-02-06 09:47, Bob Hinden wrote: ... > I was thinking that we should have a strict canonical form > along the line of what is proposed in Section 8. This format > SHOULD always be used when an IPv6 address is saved to a file > or log as text (as opposed to binary). The canonical format > would not support any of the embedded formats. Everything > would look like: > > 2001:db8:0:0:1:22::1 > > 2001:db8:0:0:1::1 > > 2001:db8:0:11:222:3333:c000:0201 > > Tools could be built that would allow alternative ways to > display the addresses in the file. For example in the second > case above, it could be displayed as: > > 2001:db8:0:11:222:3333:192.0.2.1 > > All operations used to compare and search against entries in > the file would performed against the canonical format. A > search tool could allow an address to be entered in an > embedded format (or any format defined in RFC4291), but it > would convert the address to the canonical format before the > search is performed. > > This is similar to the way something a spread sheet deals > with dates and times. The underlying data does not change if > the user decides to change the format it is displayed. Or > this is the way that I think tools like tcpdump deal with > saved packet traces. It gives the user control over how the > data is displayed, but the data in the file is in a general > format. > > In this approach, a specific tool would always work to show > the user consistent address formats and avoid the problems > enumerated in the draft. For example, if a tool knew how to > detect and show IPv6 addresses with embedded IPv4 addresses, > it would show everything that way. If the tool didn't it > would still provide the user a consistent view of the > addresses. I think this is the overall intent of this draft. But this would mean losing the ability for a human to write an address in the most appropriate way (which may or may not show a dotted decimal suffix) and then store it in that format for future use by both humans and software. And it would mean that tools with misconceptions about valid WKPs would work differently. That would break the Law of Least Astonishment. > I think this would be a better approach and allow us to solve > the problem originally as intended when the w.g. took this > work on. I thought we started this effort to help operators by reducing confusion. Discarding dotted deimal when entered by a human will not do that, IMHO. There's no doubt that internal searches and comparisons should be done against the canonical representation, of course. But I believe that dotted decimal MUST NOT be discarded by tools if entered by a human. Brian From brian.e.carpenter@gmail.com Fri Feb 5 14:52:33 2010 Return-Path: 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 68AC53A6F3B for ; Fri, 5 Feb 2010 14:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 4gvIlvwpenoo for ; Fri, 5 Feb 2010 14:52:32 -0800 (PST) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 7FF8C3A6E3C for ; Fri, 5 Feb 2010 14:52:32 -0800 (PST) Received: by ewy28 with SMTP id 28so583092ewy.28 for ; Fri, 05 Feb 2010 14:53:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=xBjTGYQVF91fk3xbqw7J9kYLnN9JU9HWIPvS7t0GIGI=; b=A4KdDPt88P8CvFXplKv0Jm6Ttnii/CpngO77iaPuySB0yNu8QPKylwjWMPGTM+JyUC T7cL0An8D1BsnSEWfzqFIYpPqXH3mZiRkjj0sY7psOfYUzJcqZaQL8PMQmr3ptEjKmnI nFXiz8Yt1X38NK0Zs36osA/3pBs+1UukqFAlo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=idQ5dmA07Ss9HbDWAkw+zuEdCMXBwxP3xnE3nScA9BWovmCKh+ZErqgkQNnc0I6hqN ib3lfwO3XlkjvryzkGPwa+TNL4GAGbR7/VbMXg9qhKbM/Vpc1HZPSduTwAwPILHtSFrb mg6OOA8iRxskPnC3GiQdjoIztONqPBAv/0JdM= Received: by 10.213.109.92 with SMTP id i28mr48705ebp.63.1265410400286; Fri, 05 Feb 2010 14:53:20 -0800 (PST) Received: from ?10.1.1.5? ([121.98.142.15]) by mx.google.com with ESMTPS id 15sm1317917ewy.4.2010.02.05.14.53.17 (version=SSLv3 cipher=RC4-MD5); Fri, 05 Feb 2010 14:53:19 -0800 (PST) Message-ID: <4B6CA159.9090806@gmail.com> Date: Sat, 06 Feb 2010 11:53:13 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?0KDQvtC80LDQvSDQlNC+0L3Rh9C10L3QutC+?= Subject: Re: next steps with 6man-text-addr-representation References: <4B6C14D2.60304@piuha.net> <4B6C87E0.7040101@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 22:52:33 -0000 On 2010-02-06 10:14, =D0=A0=D0=BE=D0=BC=D0=B0=D0=BD =D0=94=D0=BE=D0=BD=D1= =87=D0=B5=D0=BD=D0=BA=D0=BE wrote: > Brian E Carpenter =D0=BF=D0=B8=D1=81=D0=B0= =D0=BB =D0=B2 =D1=81=D0=B2=D0=BE=D1=91=D0=BC =D0=BF=D0=B8=D1=81=D1=8C=D0=BC= =D0=B5 > Sat, 06 Feb 2010 00:04:32 +0300: >=20 >> Also, I just came across something "interesting". RFC 3986 cites RFC >> 2234. >> In the latter, we find >> HEXDIG =3D DIGIT / "A" / "B" / "C" / "D" / "E" / "F" >> Unfortunately, that means that the URI format (and dependencies such >> as SIP) don't allow lower case hex. That is inconsistent with >> the current draft. Oops. >> >> [Note to self - this also messes up draft-ietf-sip-ipv6-abnf-fix-04, >> of which I'm a co-author.] >=20 > ABNF string literals are case-insensitive. As I noted to Alexey, that's fine for conformance but not for generation. Bian From dougb@dougbarton.us Fri Feb 5 15:58:09 2010 Return-Path: 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 2AA573A6FAC for ; Fri, 5 Feb 2010 15:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] 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 za4Ttet3yOaS for ; Fri, 5 Feb 2010 15:58:08 -0800 (PST) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by core3.amsl.com (Postfix) with ESMTP id 092A63A6FAA for ; Fri, 5 Feb 2010 15:58:07 -0800 (PST) Received: (qmail 3152 invoked by uid 399); 5 Feb 2010 23:58:59 -0000 Received: from localhost (HELO ?192.168.0.110?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 5 Feb 2010 23:58:59 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B6CB0CF.3050107@dougbarton.us> Date: Fri, 05 Feb 2010 15:59:11 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: next steps with 6man-text-addr-representation References: <4B6C14D2.60304@piuha.net> <4B6C87E0.7040101@gmail.com> <4B6C88F2.8040406@isode.com> <4B6C9DA0.9010904@gmail.com> In-Reply-To: <4B6C9DA0.9010904@gmail.com> X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 23:58:09 -0000 On 2/5/2010 2:37 PM, Brian E Carpenter wrote: > Oh, OK, that is fine for conformance of course, but leaves things > open when you are talking about generating strings. If we want the > new recommendation to be a MUST, we may have to consider wording to > make it clear how widely it applies. Many existing specs may be > affected implicitly. Would something like this work? In the absence of a conflicting specification, ... MUST ... At the time of this writing the following specifications are known to conflict: Doug PS, I'm sure the thought has occurred to others already, but the fact that something like this has become so complicated is almost certainly a symptom that something is wrong on a more fundamental level .... -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From bob.hinden@gmail.com Fri Feb 5 16:18:48 2010 Return-Path: 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 DFEEC3A6E83 for ; Fri, 5 Feb 2010 16:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 vjAMllOmegtU for ; Fri, 5 Feb 2010 16:18:48 -0800 (PST) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id D955E3A6996 for ; Fri, 5 Feb 2010 16:18:47 -0800 (PST) Received: by ewy28 with SMTP id 28so645797ewy.28 for ; Fri, 05 Feb 2010 16:19:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=EV9PNvBjdSLpcjjryUgDPE37rNt59NEwA8DgB7TWxlI=; b=u7qCLBOKTCRtPVkdWg7C3Qg6dRvtvZ6WkHukz8Og0YJmwz+rVvzbzWMqXeR+50tGGQ oPxLaEYaPJpZOju8vAXCU88ok3eQdxl7mpUX30fQZibOV5TbmsHiKLZSeJkuQAKTW0Tn sy01e1wuG2fYQ8M+Ebrvlbw7jP+tjS6TJ7CCI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=b404tyjkcxOITjZMKNU2dL10VccYddr7Bh03KaHX4I1MwTTmeCKTxZxbc8wS3lzLe8 g/wp1yIsLTr9NzxYJXFWfuOmsbNE+tn4zdjoKuEpj73Cb8LHoYtekfSAzIstyZtvM4WE NfohVzz3gOkQGc5oGf0miYLSp683yYXa9SLzg= Received: by 10.213.48.2 with SMTP id p2mr1218014ebf.60.1265415577045; Fri, 05 Feb 2010 16:19:37 -0800 (PST) Received: from ?209.97.124.223? ([209.97.124.223]) by mx.google.com with ESMTPS id 15sm1362063ewy.4.2010.02.05.16.19.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 05 Feb 2010 16:19:36 -0800 (PST) Subject: Re: next steps with 6man-text-addr-representation Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <4B6CB0CF.3050107@dougbarton.us> Date: Fri, 5 Feb 2010 16:19:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B6C14D2.60304@piuha.net> <4B6C87E0.7040101@gmail.com> <4B6C88F2.8040406@isode.com> <4B6C9DA0.9010904@gmail.com> <4B6CB0CF.3050107@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1077) Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2010 00:18:49 -0000 Doug, On Feb 5, 2010, at 3:59 PM, Doug Barton wrote: > On 2/5/2010 2:37 PM, Brian E Carpenter wrote: >> Oh, OK, that is fine for conformance of course, but leaves things >> open when you are talking about generating strings. If we want the >> new recommendation to be a MUST, we may have to consider wording to >> make it clear how widely it applies. Many existing specs may be >> affected implicitly. >=20 > Would something like this work? >=20 > In the absence of a conflicting specification, ... MUST ... At the = time > of this writing the following specifications are known to conflict: = That's essentially the definition of SHOULD. It's what you do unless = there is a compelling reason not to do it. Bob From alexey.melnikov@isode.com Fri Feb 5 13:08:45 2010 Return-Path: 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 CFEBE3A67B4; Fri, 5 Feb 2010 13:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599] 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 il7b8d8ePmkt; Fri, 5 Feb 2010 13:08:45 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id D62D23A67AC; Fri, 5 Feb 2010 13:08:44 -0800 (PST) Received: from [172.16.2.152] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 5 Feb 2010 21:09:35 +0000 Message-ID: <4B6C88F2.8040406@isode.com> Date: Fri, 05 Feb 2010 21:09:06 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Brian E Carpenter Subject: Re: next steps with 6man-text-addr-representation References: <4B6C14D2.60304@piuha.net> <4B6C87E0.7040101@gmail.com> In-Reply-To: <4B6C87E0.7040101@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 06 Feb 2010 08:43:00 -0800 Cc: draft-ietf-6man-text-addr-representation@tools.ietf.org, IESG , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 21:08:45 -0000 Hi Brian, Brian E Carpenter wrote: [...] >>- Provide a reference to the currently defined WKPs >>- In the section that talks about ports, please make sure that for URIs >>everyone MUST follow RFC 3986, and for the rest, the default can be >>again RFC 3986. The current language leaves everything open, even for URIs. >> >> >We have to phrase this rather carefully. There is valid normative ABNF >for the RFC 4291 representation in RFC 3986, but it does not generate >only the proposed canonical representation. It allows leading zeroes, >for example, and allows zeroes instead of ::. > >Also, I just came across something "interesting". RFC 3986 cites RFC 2234. >In the latter, we find >HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" >Unfortunately, that means that the URI format (and dependencies such >as SIP) don't allow lower case hex. That is inconsistent with >the current draft. Oops. > > Actually no, all quoted strings in ABNF are case-insensitive. So "A" matches both "A" and "a", etc. >[Note to self - this also messes up draft-ietf-sip-ipv6-abnf-fix-04, >of which I'm a co-author.] > > [...] >>- We will keep the specification on the Standards Track, i.e., publish >>it as a Proposed Standard >>- This specification Updates RFC 4291 >> >> > >In that case we need to state explicitly that lower case hex is >allowed; > Showing such examples would be fine, but see above. >4291 only shows upper case examples. > > From brian.e.carpenter@gmail.com Sat Feb 6 13:39:43 2010 Return-Path: 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 119383A6993 for ; Sat, 6 Feb 2010 13:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599] 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 8SwuxwrTkW2j for ; Sat, 6 Feb 2010 13:39:42 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 142CB3A68D1 for ; Sat, 6 Feb 2010 13:39:41 -0800 (PST) Received: by gxk28 with SMTP id 28so4277656gxk.9 for ; Sat, 06 Feb 2010 13:40:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=e02BLkSfN12WOH+Jb0WzTrf2EJ08LgHQx86iOBEP5/M=; b=vs39IHQWQ4+JvnAqUeyBMu/efYw/NU4i1zBtAn8EZYvnwadVrDDjPDl6ih41hbnVCi q92i75DwFpqHfWhNYU/O++8mh2lzCJIUo1Rlj6Thsn/qYB5Zjyg1Ru2+PeD9DJMLRtXu higQDcBzGjM7W2C/XXfx3zkvaCujGJmXfeUDA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=mToaOyA4qNCN+wuCdtsAcFJ9CbmN/YTIXJPTNm3l3NWDrSGMJa6ooFmad5PxRST+/0 0GP9c0ASJp0+DOVdV3Rsng/MLcI8mKW37LSAgjdjQ0aPizFOmwHEyUIx2G5LtC7MQrcx UHu7tF/QQqjgPHoKThfmKRP9QvF3Tz7BqLJ/k= Received: by 10.90.14.13 with SMTP id 13mr4009623agn.112.1265492432465; Sat, 06 Feb 2010 13:40:32 -0800 (PST) Received: from ?10.1.1.5? ([121.98.142.15]) by mx.google.com with ESMTPS id 21sm909591ywh.46.2010.02.06.13.40.29 (version=SSLv3 cipher=RC4-MD5); Sat, 06 Feb 2010 13:40:31 -0800 (PST) Message-ID: <4B6DE1C5.2020404@gmail.com> Date: Sun, 07 Feb 2010 10:40:21 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Bob Hinden Subject: Re: next steps with 6man-text-addr-representation References: <4B6C14D2.60304@piuha.net> <4B6C87E0.7040101@gmail.com> <4B6C88F2.8040406@isode.com> <4B6C9DA0.9010904@gmail.com> <4B6CB0CF.3050107@dougbarton.us> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2010 21:39:43 -0000 On 2010-02-06 13:19, Bob Hinden wrote: > Doug, > > On Feb 5, 2010, at 3:59 PM, Doug Barton wrote: > >> On 2/5/2010 2:37 PM, Brian E Carpenter wrote: >>> Oh, OK, that is fine for conformance of course, but leaves things >>> open when you are talking about generating strings. If we want the >>> new recommendation to be a MUST, we may have to consider wording to >>> make it clear how widely it applies. Many existing specs may be >>> affected implicitly. >> Would something like this work? >> >> In the absence of a conflicting specification, ... MUST ... At the time >> of this writing the following specifications are known to conflict: > > That's essentially the definition of SHOULD. It's what you do unless there is a compelling reason not to do it. [Digression: a sad fact of life is that this is what MUST means in practice. And SHOULD means "product managers who are short of programmers MAY leave this out".] I was rather thinking that we have to say MUST (as the IESG wishes) and then add something like: The following specifications, among others, are affected by this requirement: RFC 3986, ... I think this will demonstrate the scope of this change from SHOULD to MUST. Brian From dougb@dougbarton.us Sat Feb 6 18:18:36 2010 Return-Path: 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 49D3428C102 for ; Sat, 6 Feb 2010 18:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] 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 zIswrzWctC3H for ; Sat, 6 Feb 2010 18:18:32 -0800 (PST) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by core3.amsl.com (Postfix) with ESMTP id D1D233A714C for ; Sat, 6 Feb 2010 18:18:31 -0800 (PST) Received: (qmail 21757 invoked by uid 399); 7 Feb 2010 02:19:27 -0000 Received: from localhost (HELO ?192.168.0.110?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 7 Feb 2010 02:19:27 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B6E233B.3060806@dougbarton.us> Date: Sat, 06 Feb 2010 18:19:39 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: next steps with 6man-text-addr-representation References: <4B6C14D2.60304@piuha.net> <4B6C87E0.7040101@gmail.com> <4B6C88F2.8040406@isode.com> <4B6C9DA0.9010904@gmail.com> <4B6CB0CF.3050107@dougbarton.us> <4B6DE1C5.2020404@gmail.com> In-Reply-To: <4B6DE1C5.2020404@gmail.com> X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 02:18:36 -0000 On 2/6/2010 1:40 PM, Brian E Carpenter wrote: > On 2010-02-06 13:19, Bob Hinden wrote: >> Doug, >> >> On Feb 5, 2010, at 3:59 PM, Doug Barton wrote: >> >>> On 2/5/2010 2:37 PM, Brian E Carpenter wrote: >>>> Oh, OK, that is fine for conformance of course, but leaves things >>>> open when you are talking about generating strings. If we want the >>>> new recommendation to be a MUST, we may have to consider wording to >>>> make it clear how widely it applies. Many existing specs may be >>>> affected implicitly. >>> Would something like this work? >>> >>> In the absence of a conflicting specification, ... MUST ... At the time >>> of this writing the following specifications are known to conflict: >> >> That's essentially the definition of SHOULD. It's what you do unless there is a compelling reason not to do it. > > [Digression: a sad fact of life is that this is what MUST means > in practice. And SHOULD means "product managers who are short > of programmers MAY leave this out".] Heh. > I was rather thinking that we have to say MUST (as the IESG > wishes) and then add something like: > The following specifications, among others, are affected by > this requirement: RFC 3986, ... > I think this will demonstrate the scope of this change from > SHOULD to MUST. Yeah, I was opposed to there even being a SHOULD in 2119, but IIRC I never even bothered to voice that opinion. There are only so many windmills I can tilt at. However, getting away from the digression to the digression to the digression, FWIW I agree with your suggestion Brian, and I would have also preferred "MUST" from the beginning in any case. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From lars.eggert@nokia.com Mon Feb 8 02:05:27 2010 Return-Path: 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 250F03A7329; Mon, 8 Feb 2010 02:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 zWInhf0Ker1w; Mon, 8 Feb 2010 02:05:26 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 990183A7328; Mon, 8 Feb 2010 02:05:25 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o18A5r4R000306; Mon, 8 Feb 2010 12:06:23 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Feb 2010 12:06:23 +0200 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Feb 2010 12:06:16 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o18A6Er3006875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2010 12:06:14 +0200 Subject: Re: next steps with 6man-text-addr-representation X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-6--446440507; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <0C32BEB8-EE9B-40A9-A3E7-253F498A6C20@gmail.com> Date: Mon, 8 Feb 2010 12:06:08 +0200 Message-Id: References: <4B6C14D2.60304@piuha.net> <0C32BEB8-EE9B-40A9-A3E7-253F498A6C20@gmail.com> To: Bob Hinden X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Mon, 08 Feb 2010 12:06:08 +0200 (EET) X-OriginalArrivalTime: 08 Feb 2010 10:06:16.0747 (UTC) FILETIME=[5A5B97B0:01CAA8A6] X-Nokia-AV: Clean Cc: "draft-ietf-6man-text-addr-representation@tools.ietf.org" , IESG , IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 10:05:27 -0000 --Apple-Mail-6--446440507 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, what Bob outlines below is pretty exactly what I thought the intent of = this ID was supposed to be, and going in this direction would certainly = address my discuss. Lars On 2010-2-5, at 22:47, Bob Hinden wrote: > Jari, >=20 >> Then we talked about the strictness. I explained that this is largely = a specification style issue, and in the real world there will always be = old code that doesn't produce the canonical form, and that we hope that = this RFC will convince all new code to do the right thing. However, we = came up with the following proposal to make the specification stricter: >>=20 >> - Use RFC 2119 language and MUST. Implementations conforming to this = specification MUST ... >> - Provide a reference to the currently defined WKPs >> - In the section that talks about ports, please make sure that for = URIs everyone MUST follow RFC 3986, and for the rest, the default can be = again RFC 3986. The current language leaves everything open, even for = URIs. >> - There's a part about reducing longest sequence of 0s -- it would be = great if we could point to some publicly available code that already = does this, as an informational reference to implementors >> - We will keep the specification on the Standards Track, i.e., = publish it as a Proposed Standard >> - This specification Updates RFC 4291 >>=20 >> Would these changes be acceptable to the working group? >=20 > [No hats on] >=20 > I was thinking about this over the past few days after reading the = IESG comments and a discussion with Brian Haberman. My personal take is = that we lost sight of the original goal while trying to meet the broad = requirements of the different variants of embedded addresses. >=20 > I was thinking that we should have a strict canonical form along the = line of what is proposed in Section 8. This format SHOULD always be = used when an IPv6 address is saved to a file or log as text (as opposed = to binary). The canonical format would not support any of the embedded = formats. Everything would look like: >=20 > 2001:db8:0:0:1:22::1 >=20 > 2001:db8:0:0:1::1 >=20 > 2001:db8:0:11:222:3333:c000:0201 >=20 > Tools could be built that would allow alternative ways to display the = addresses in the file. For example in the second case above, it could = be displayed as: >=20 > 2001:db8:0:11:222:3333:192.0.2.1 >=20 > All operations used to compare and search against entries in the file = would performed against the canonical format. A search tool could allow = an address to be entered in an embedded format (or any format defined in = RFC4291), but it would convert the address to the canonical format = before the search is performed. >=20 > This is similar to the way something a spread sheet deals with dates = and times. The underlying data does not change if the user decides to = change the format it is displayed. Or this is the way that I think = tools like tcpdump deal with saved packet traces. It gives the user = control over how the data is displayed, but the data in the file is in a = general format. >=20 > In this approach, a specific tool would always work to show the user = consistent address formats and avoid the problems enumerated in the = draft. For example, if a tool knew how to detect and show IPv6 = addresses with embedded IPv4 addresses, it would show everything that = way. If the tool didn't it would still provide the user a consistent = view of the addresses. I think this is the overall intent of this = draft. >=20 > I think this would be a better approach and allow us to solve the = problem originally as intended when the w.g. took this work on. >=20 > I would appreciate your and the w.g.'s comments. >=20 > Thanks, > Bob >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 --Apple-Mail-6--446440507 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDIwODEwMDYwOFowIwYJKoZIhvcNAQkEMRYEFFJ1dDDEG5qkGbcSWHJ2wWmrmrmRMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQAceWg9onAMFtt8yFpYonth23hXcvvtHqCIpuPG17YonzNRzpNHG7c/JNX0CWPDtrega+fv VBI2e28BXG1gjbDJrf4WmUxUmsuvnYytojS0N+bQGcnV4rreAj6YEQQSjly8026/dilDN/ywXr7/ EAGZUBgT7Mw97GY8VPbZChrgZlPe0voMf/JqF0XU3PBAdkfFead2NYkZryQl03s/GicWg5bEJBDn wMUSgKxW6ifbX8A5KaCCbAiYP5n/8mpw+FdgdV6Ni0pZyig56LcJ6jsKasVSq99ju0Kxi09Vydnh T6VumFupJW72gbLbjlQmeU+SDr4tyX/6ry4UA4tbVPwLAAAAAAAA --Apple-Mail-6--446440507-- From kawamucho@mesh.ad.jp Mon Feb 8 03:37:06 2010 Return-Path: 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 1DC303A7367; Mon, 8 Feb 2010 03:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_34=0.6] 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 na04n-sRJbIb; Mon, 8 Feb 2010 03:37:05 -0800 (PST) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by core3.amsl.com (Postfix) with ESMTP id 1A5CD3A7364; Mon, 8 Feb 2010 03:37:04 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.195]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id o18Bc6pb008553; Mon, 8 Feb 2010 20:38:06 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id o18Bc5R01383; Mon, 8 Feb 2010 20:38:05 +0900 (JST) Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv3.nec.co.jp (8.13.8/8.13.4) with ESMTP id o18Bc5lk003891; Mon, 8 Feb 2010 20:38:05 +0900 (JST) Received: from bsac29088.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o18Bc5Kp028896; Mon, 8 Feb 2010 20:38:05 +0900 Received: from mail.sys.biglobe.nec.co.jp (bgsx5626.sys.biglobe.nec.co.jp [10.18.151.10]) by bsac29088.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o18Bc59l005941; Mon, 8 Feb 2010 20:38:05 +0900 Received: from [127.0.0.1] (edonet065.sys.biglobe.nec.co.jp [10.19.137.65]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o18Bc5Ah027832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2010 20:38:05 +0900 Message-ID: <4B6FF79B.2050202@mesh.ad.jp> Date: Mon, 08 Feb 2010 20:38:03 +0900 From: Seiichi Kawamura User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jari Arkko Subject: Re: next steps with 6man-text-addr-representation References: <4B6C14D2.60304@piuha.net> <201002051317.o15DH5Rh065500@drugs.dv.isc.org> <4B6C1DDF.70904@piuha.net> In-Reply-To: <4B6C1DDF.70904@piuha.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-6man-text-addr-representation@tools.ietf.org, IETF IPv6 Mailing List , IESG , Mark Andrews X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: ,