Re: Fwd: RFC 3484 Section 6 Rule 9
Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 22 June 2009 09:48 UTC
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAA863A689D for <ipv6@core3.amsl.com>; Mon, 22 Jun 2009 02:48:00 -0700 (PDT)
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 qoqo7U9OE8Qf for <ipv6@core3.amsl.com>; Mon, 22 Jun 2009 02:48:00 -0700 (PDT)
Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id A1EC13A6828 for <ipv6@ietf.org>; Mon, 22 Jun 2009 02:47:59 -0700 (PDT)
Received: by ewy6 with SMTP id 6so4534667ewy.37 for <ipv6@ietf.org>; Mon, 22 Jun 2009 02:48:12 -0700 (PDT)
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=n0dzHVikbFJOGZN5kcu8LDJS/fnU8nh1W7xpWb6Ms3w=; b=goLgMSzT4S+WRNIv6+cnujaZmTaca/69huZv6PFg+2TX6X8B/dlW0Eu2pdeBzrTq9E CKKZyAj9CezrY3nkyrx/xp6Nz0CoL7W8aP5SY5TiYvhBwjuEp3voBKwLvFib1baqsQ5h HVb8vE6KLVWX/NPkoTC3Hwc7TRAe3ZoygYrVs=
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=woczrue8ZAdfY4BIXubAXI4WIhcVCi5KxrGncXsCRemL0NE+cbRjpW3xBihiPiZjuK DnVFc0fiW0ydbZ0VRMzF43/1pFr+udrb/SGpuqZLsIUmFN5oj1sQ4S+3zUJ8yVmz4mEr snUGpDQaAGQQBYSLsXn7NZo7hZpWGMXtnUz/A=
Received: by 10.210.133.19 with SMTP id g19mr7084159ebd.46.1245664092428; Mon, 22 Jun 2009 02:48:12 -0700 (PDT)
Received: from ?192.168.1.65? (host81-157-83-244.range81-157.btcentralplus.com [81.157.83.244]) by mx.google.com with ESMTPS id 24sm76172eyx.13.2009.06.22.02.48.10 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Jun 2009 02:48:11 -0700 (PDT)
Message-ID: <4A3F5355.3050104@gmail.com>
Date: Mon, 22 Jun 2009 10:48:05 +0100
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Arifumi Matsumoto <a@arifumi.net>
Subject: Re: Fwd: RFC 3484 Section 6 Rule 9
References: <C46AB084.3A7B8%leo.vegoda@icann.org> <4845B998.1010401@gmail.com> <884C2127-D98B-472E-B245-D18CE61D4018@ca.afilias.info> <48461822.8070608@gmail.com> <88E5E85A-3446-4490-B552-D8C624EC82F6@nttv6.net> <4849CE64.4080205@gmail.com> <7b1e7a950806061901i6364c2a7u26c6172190b1801b@mail.gmail.com>
In-Reply-To: <7b1e7a950806061901i6364c2a7u26c6172190b1801b@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jun 2009 09:48:01 -0000
Hi, Sorry about the late reply. I agree with this (that is, choice 3 in section 2.6 of draft-arifumi-6man-rfc3484-revise-01). Regards Brian On 2008-06-07 03:01, Arifumi Matsumoto wrote: > Let me switch to 6man ML. > # Brian, thank you for redirection ;) > > Regarding this issue of RFC 3484 section 6 rule 9, > let me give you my two cents, which is conditional longest > matching rule application. > > When the length of matching bits of the destination > address and the source address is longer than N, > the rule 9 is applied. Otherwise, the order of the > destination addresses do not change. (For DNS-RR) > > The N should be configurable and I guess it should be 32 > by default. This is simply because the two sites whose > matching bit length is longer than 32 are probably > adjacent. > > Regards, > Arifumi Matsumoto > > On 2008/06/04, at 13:20, Brian E Carpenter wrote: > >> Joe, >> >>> It seems to me that direct assignment could quite possibly become the >>> default for small IPv6 sites in the ARIN region. IPv6 uptake to >>> date has >>> been so tiny that I don't think anybody can predict what behaviours >>> will >>> become prevalent if/when IPv6 takes off. >> We can't predict how economic actors will choose to act. What we can >> predict >> is catastrophe if ten or 100 million sites attempt to push /48 >> advertisements >> out into BGP4. It would be highly irresponsible of any registry to >> pursue >> a policy that leads to such a result, until we have a technical >> solution >> to the resulting scaling problem. It's exactly because we don't have >> such >> a solution that the IPv6 design model is PA. >> >> I'm not shocked at the notion of a few hundred thousand early >> adopters of >> IPv6 getting PI prefixes. But that's a very different matter than >> millions. >> >> (This remains directly relevant to the subject of this thread. The >> infamous Rule 9 exists, right or wrong, because of PA addressing >> in IPv6.) >> >> Brian >> _______________________________________________ >> IETF mailing list >> IETF@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
- Re: RFC 3484 Section 6 Rule 9 Brian E Carpenter
- Fwd: RFC 3484 Section 6 Rule 9 Arifumi Matsumoto
- Re: Fwd: RFC 3484 Section 6 Rule 9 Brian E Carpenter
- Re: RFC 3484 Section 6 Rule 9 Arifumi Matsumoto