Re: [Autoconf] Working Group Last Call for draft-ietf-autoconf-addr-model-01

Mark Townsley <townsley@cisco.com> Wed, 20 January 2010 11:26 UTC

Return-Path: <townsley@cisco.com>
X-Original-To: autoconf@core3.amsl.com
Delivered-To: autoconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE6093A68E4 for <autoconf@core3.amsl.com>; Wed, 20 Jan 2010 03:26:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.532
X-Spam-Level:
X-Spam-Status: No, score=-10.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 MnL8dSIkrC0g for <autoconf@core3.amsl.com>; Wed, 20 Jan 2010 03:26:06 -0800 (PST)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 01E833A6A3E for <autoconf@ietf.org>; Wed, 20 Jan 2010 03:25:50 -0800 (PST)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApsEAFN3VkurR7Hu/2dsb2JhbACBRsBTlUGENgQ
X-IronPort-AV: E=Sophos;i="4.49,309,1262563200"; d="scan'208";a="76786016"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 20 Jan 2010 11:25:46 +0000
Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o0KBPkPD016361; Wed, 20 Jan 2010 11:25:46 GMT
Received: from Saturn.local (dhcp-10-55-80-146.cisco.com [10.55.80.146]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o0KBPiW26428; Wed, 20 Jan 2010 03:25:45 -0800 (PST)
Message-ID: <4B56E834.4060800@cisco.com>
Date: Wed, 20 Jan 2010 12:25:40 +0100
From: Mark Townsley <townsley@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0
MIME-Version: 1.0
To: Thomas Narten <narten@us.ibm.com>
References: <3A8500A3-A75A-49A8-B48C-EED53A17E722@computer.org> <201001051958.o05Jw3vF025489@cichlid.raleigh.ibm.com>
In-Reply-To: <201001051958.o05Jw3vF025489@cichlid.raleigh.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: autoconf@ietf.org
Subject: Re: [Autoconf] Working Group Last Call for draft-ietf-autoconf-addr-model-01
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jan 2010 11:26:08 -0000

On 1/5/10 8:58 PM, Thomas Narten wrote:
> Two comments on this document.
>
> The document uses but does not really define the term "routing
> domain". It should define and/or explain what this term means and why
> the term is important (in the context of this document).
>    

We can reference RFC 1136 for this (but I'd hate to have to use the ISO 
"routeing" spelling, it just hurts my eyes).

>    
>> 6.1.  IPv6 Model
>>
>>     For IPv6, the principles described in Section 4 and Section 5 suggest
>>     the following rules:
>>
>>      
>   ...
>    
>>     o  No on-link subnet prefix is configured on this interface.
>>
>>      
> But:
>
>    
>> 6.2.  IPv4 Model
>>
>>     For IPv4, the principles described in Section 4 and Section 5 suggest
>>     rules similar to those mentioned for IPv6 in Section 6.1, that are:
>>
>>      
> ...
>    
>>     o  Any subnet prefix configured on this interface should be of length
>>        /32.
>>      
> I don't see a lot of difference between an IPv6 "on-link" prefix and
> an IPv4 subnet prefix. It doesn't make sense to me that IPv6 and IPv4
> are treated differently.
>    
I think I was the one who actively supported treating IPv6 and IPv4 
differently in the document. IPv6 has a ULA range, IPv4 doesn't. IPv4 
has a Private range, IPv6 doesn't. IPv4 global space is constrained, 
IPv6 isn't. IPv4 stacks remove IPv4 link-local addresses from an 
interface when a global or private is assigned, IPv6 stacks do not... 
etc... etc... So, while there certainly are commonalities in the models, 
there are enough differences that describing each model separately seems 
to reduce the chance of misunderstanding the differences that do exist 
between one version vs. the other.

- Mark

> Thomas
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf
>
>