Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05

Joel Jaeggli <joelja@bogus.com> Sat, 21 August 2010 04:50 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: int-area@core3.amsl.com
Delivered-To: int-area@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 256743A69B4 for <int-area@core3.amsl.com>; Fri, 20 Aug 2010 21:50:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.288
X-Spam-Level:
X-Spam-Status: No, score=-102.288 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrbN8rDij-A3 for <int-area@core3.amsl.com>; Fri, 20 Aug 2010 21:49:54 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 7C3233A6838 for <int-area@ietf.org>; Fri, 20 Aug 2010 21:49:53 -0700 (PDT)
Received: from joelja-mac.lan (c-98-234-104-156.hsd1.ca.comcast.net [98.234.104.156]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id o7L4oLqM092714 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for <int-area@ietf.org>; Sat, 21 Aug 2010 04:50:23 GMT (envelope-from joelja@bogus.com)
Message-ID: <4C6F5B0C.2030803@bogus.com>
Date: Fri, 20 Aug 2010 21:50:20 -0700
From: Joel Jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2
MIME-Version: 1.0
To: int-area@ietf.org
References: <D74F3837-E115-49FB-A9AB-5E0C53406621@tony.li> <C0AC8FAB6849AB4FADACCC70A949E2F1058062E62F@EUSAACMS0701.eamcs.ericsson.se> <188C11C5-CDBA-4213-83AC-453AE06ADAD5@cisco.com> <4C6EE713.9080805@gmail.com> <C0AC8FAB6849AB4FADACCC70A949E2F1058062E716@EUSAACMS0701.eamcs.ericsson.se> <FE3A892F-DF2F-407A-88D8-54ABF7221308@cisco.com>
In-Reply-To: <FE3A892F-DF2F-407A-88D8-54ABF7221308@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Sat, 21 Aug 2010 04:50:23 +0000 (UTC)
Subject: Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/int-area>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Aug 2010 04:50:01 -0000

On 8/20/10 4:00 PM, Fred Baker wrote:
> 
> On Aug 20, 2010, at 2:55 PM, Eric Gray wrote:
> 
>> Following the CIDR model for IPv6 seems to allow for as many as (on
>> the order of) 7-10 times as many possibly usable address allocation
>> sizes.
> 
> Well, yes, saying that "you can pick any length you like" gives the
> address allocation authorities, at least in theory, 64 orders of
> magnitude.
> 
> There is a line of reasoning, which I subscribe to, that all of those
> options really aren't needed, and that there are human factors
> reasons to prefer prefix lengths on nibble (hex digit) boundaries.
> Not that allocations like 192.0.2.20/30 are impossible to grok -
> they're not - but if we have the opportunity to simplify things, why
> not?
> 
> One comment that comes to mind is a recent conversation with my son.
> He works for a company that makes radio-controlled model airplanes,
> the kind that have a 66 foot wingspan and shoot missiles. The planes
> are full of computers, and no they don't ask the DNS root to
> translate names. If you're in one of those computers and need to talk
> with another one, you need to know its IP address. So he is used to
> being in computer A and logging into computer B as 192.0.2.17 or
> whatever.
> 
> He and I spoke a few weeks about, and he asked "Dad, when you guys
> were designing IPv6, did you think at all about how LONG those
> addresses were?"
> 
> ta-dum!
> 
> Now ask yourself about being in my daughter's network (women enter
> her home as the girl-next-door and leave beautiful), telling her that
> she can use anything she likes in 2001:0db8:2775:1234/62, and having
> her notice that the address of something or another is
> 2001:0db8:2775:1235... In IPv4, I said "deal with it, you have to be
> somewhat technical". In IPv6, I would like to not have to go there.
> It's not her expertise, and she doesn't ask me to cut/color her hair
> either.
> 
> So, yes, I tend to think that the common rabble should deal with
> addresses that break on nibble boundaries.

As I observed not so long ago at a v6ops wg meeting. having your your
foo object (in the case described a point to point link) aligned on
octet or nibble boundaries makes them way easier to read. have a few
thousands 126 or 127 prefixes in a row and it kind of looks like fruit
salad.

Just because the robots don't have trouble with it doesn't mean the
humans  shouldn't be accommodated.

> That has nothing to do with RIRs or service providers, mind you; they
> are often "somewhat technical". Within their networks I expect them
> to do what makes sense to them, and I regard myself more as their
> student than their teacher... 
> _______________________________________________ Int-area mailing
> list Int-area@ietf.org 
> https://www.ietf.org/mailman/listinfo/int-area
>