Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt

Mark ZZZ Smith <markzzzsmith@yahoo.com.au> Fri, 20 February 2015 04:15 UTC

Return-Path: <markzzzsmith@yahoo.com.au>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5EE1A6EED for <v6ops@ietfa.amsl.com>; Thu, 19 Feb 2015 20:15:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.501
X-Spam-Level:
X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HK_RANDOM_REPLYTO=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wCConNsBqLb for <v6ops@ietfa.amsl.com>; Thu, 19 Feb 2015 20:15:53 -0800 (PST)
Received: from nm41.bullet.mail.ne1.yahoo.com (nm41.bullet.mail.ne1.yahoo.com [98.138.120.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5535B1A1B14 for <v6ops@ietf.org>; Thu, 19 Feb 2015 20:15:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1424405752; bh=CFWTRqB4ppeRbV3mdKug3eq7AJB9C0JD/vebMLnVzl4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=Z/m+6erLwa9phPC+7PugemdGWas2scrrsVPjCM2KqT4tnlzoxMaXxGh7wT2iVKlsknK86krZuEOeEaQy4Z4/2mkkzl/MCQLyfj7WwnxPJ94hoXK23eOl13jeyxKYGR3FlWZzj/78BUIh1FXOAa7XCUDYG/E88+7+bjJtG4h0CVCpiR8BSnGisb7HK6u8oWwN0xh5c0l2nLC7R0HcWMu0uf/H0yZaqzse8/ctUNqOTKkgW3GPxOEgAzyXN0rwThfXDGD20LZZcPrwqTD0EB6x5mYYzX2Dn2wBfcRgiYZbdie9BiQMZJ96T0tj/NBBH71GjKDjC5CSk+5QDMQq7p/zGA==
Received: from [127.0.0.1] by nm41.bullet.mail.ne1.yahoo.com with NNFMP; 20 Feb 2015 04:15:52 -0000
Received: from [98.138.226.176] by nm41.bullet.mail.ne1.yahoo.com with NNFMP; 20 Feb 2015 04:13:11 -0000
Received: from [66.196.81.173] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 20 Feb 2015 04:13:11 -0000
Received: from [98.139.212.225] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 20 Feb 2015 04:13:11 -0000
Received: from [127.0.0.1] by omp1034.mail.bf1.yahoo.com with NNFMP; 20 Feb 2015 04:13:11 -0000
X-Yahoo-Newman-Property: ymail-4
X-Yahoo-Newman-Id: 478310.79554.bm@omp1034.mail.bf1.yahoo.com
X-YMail-OSG: LPYfcNEVM1n7wHvM7umt5ujptbmsz4ShZ_Jjivon4PMedxwpCQwuQ9VcFltuWof yWkgjw3BaD.sHWS6JfQ3OVqOhNlgK9xZxvib1C3DkMmmLV6FM5k8cRYCfouHIIRu1mIJqE3bFes2 vnLV5GOO8MHULn3pE_Gph7_XwOtQd7jrbnM7rWGR5f5S7jStcor1rsHK0rbjs7ZleYFONRCBUnmh Xsq5B6uSSAjsTSbF64O_SyJpwjfPHXMaVlqq_4F36t6gad.8OpPdgD0SETNbCMe.37BH8BNgiDbZ WKDnGWv8ZaUpz8r7tHuLwNj2xb.uODNL1K5yBJbMRb.AU22V8NIcq9ihUy04xVcEc1moCpWoSwbt y4P09iIHdQfAZuH.Q0oRpBM.QjsEL8zau7AvkRiOY7DeCA7z6eeZaeIrcXJ9CZArsuUrRLIQca23 p5f0hcIlGqFwLeR2EfM7g.LBooyxVcPawrLLpFPpxFoQwO.JncCYIggQymi__p_CU7wq6gxCy6S2 aH.99CxUNMKJHCgDkIMy.MeXfCtDF7Yu6i6BcD6gzGvdvZ_u0_KqbMch3lQh8
Received: by 66.196.81.106; Fri, 20 Feb 2015 04:13:11 +0000
Date: Fri, 20 Feb 2015 04:13:07 +0000
From: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
To: Philip Matthews <philip_matthews@magma.ca>
Message-ID: <875926930.84506.1424405587971.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <3C40DEBA-6F8F-4332-A32C-E600A25E9CD2@magma.ca>
References: <3C40DEBA-6F8F-4332-A32C-E600A25E9CD2@magma.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/KWvoF0kQP2UI-q2yO0jwmE2eNro>
Cc: v6ops list <v6ops@ietf.org>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Feb 2015 04:15:55 -0000

Hi,


----- Original Message -----
From: Philip Matthews <philip_matthews@magma.ca>
To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
Cc: v6ops list <v6ops@ietf.org>
Sent: Friday, 20 February 2015, 14:09
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt

Mark:

Thanks for your comments.  Replies inline.

Philip

On 2015-02-19, at 21:47 , Mark ZZZ Smith wrote:

> Hi,
> 
> 
> I'd like to see less implication that the choice between a single ULA and a single global prefix on a link is exclusive e.g.,
> 
> "The use of ULAs instead of globally-routed
> addresses is also not discussed;"

How about I just remove the words "instead of globally-routed addresses" from the sentence?

/I think that would do it.

> 
> "b.  Have global (or unique-local) addresses assigned in addition to
> link-locals?"
> 
> People really need to get over this (somewhat IPv4) idea that there can only be one prefix on a link (of course, in IPv6 there are always link-locals too, but the limit on link prefixes isn't two either.).

Your point is a good one, but I don't see how the quoted sentence implies that there is just one address GUA (or ULA). It does say "addresses".
I admit I may have written the section thinking of just a single GUA or ULA (in addition to the LLA), but as I re-read it, I don't see any place where that is stated or implied.


/I think 'or' in most text is interpreted as an exclusive or. I think the brackets around the 'or unique-local' further make it read like it is implying one or the other.

/"Have global and/or unique-local addresses assigned in addition to link-locals" would probably read better.

/One thought about when to use 'addresses' verses 'prefixes'. I and I think a lot of other people think at the level of assigning a prefix to a link, with the assumption and implication that all interfaces attached to the link would normally have addresses from each of the on-link prefixes. The case where link attached interfaces wouldn't have addresses from all of the present prefixes would be an exception (e.g., in IPv4, when the subnet is too small, or in IPv6, perhaps when migrating a prefix off of a link, or when the prefix has been configured on a stateful DHCPv6 server, but not all hosts have asked for addresses from it.)

/ "2.1.2.  Interfaces with Only Link-Local Addresses?" seems to be written from with the unstated assumption that all interfaces will have addresses from all on-link prefixes. As that isn't an IPv6 requirement, I think it would be best to state that assumption, and that there may be situations where that is not the case. 

/ More broadly, it seems that although interfaces are where addresses are assigned, this whole topic is really about whether to assign certain types of prefix to a link or not (and therefore implicitly all link-attached interfaces), rather than to individual interfaces or not. So I wonder if it might be a bit clearer if the perspective was changed slightly from addresses assigned to interfaces (implicitly all interfaces on a link) to prefixes assigned to links, and then stating the assumption that in most cases all interfaces will get addresses from all on-link prefixes. 



> 
> "Proper" support for multiple prefixes on a link is one of IPv6's enhanced capabilities over IPv4's. People should be encouraged to take advantage of it if it would be useful to them.

I agree, though it is not often I find an situation where I can take advantage of this.

/ I think the case for ULAs is when link-local reachability is too small, and global scope reachability is too large, because it reduces security. For example, addressing internal only servers/services (e.g., network printers), or network equipment management addresses.



Regards,
Mark.

> 
> Regards,
> Mark.
> 
> 
> 
> 
> 
> ----- Original Message -----
> From: Philip Matthews <philip_matthews@magma.ca>
> To: v6ops list <v6ops@ietf.org>
> Cc: 
> Sent: Thursday, 19 February 2015, 8:23
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt
> 
> Hi Everyone:
> 
> Victor and I just posted this update, which addresses the comments raised in Honolulu, and generally cleans up the draft. No really big changes, but lots of little changes.  
> 
> A few highlights:
> * The wording in the title, abstract and introduction has been modified to narrow the scope of the document. The document no longer claims to cover all choices around designing IPv6 network, but just certain choices that are routing-related. This always been the de-facto situation, but now the introduction etc reflect this.  Some additional sentences saying "X is not covered here, see doc Y" have also been added. Thanks to Dave Thaler and Eric Vyncke for suggestions in this area.
> * The text around using BGP sessions to link-local addresses has been updated after some email exchanges with Francis Dupont (co-author of RFC 2545), who observed that RFC 2545 forbids this (even though most vendors support it).
> * The text around security of link-local addresses has been modified since some routers forward packets containing link-local source addresses. Thanks to Jen Lincova for pointing this out.
> * The initial few sentences in a number of sections has been changed in an attempt to improve the document flow.
> * The document now has a security considerations section. There is nothing earth-shaking here; Victor and I elected to just point to some existing documents that are relevant to the choices discussed in the document.
> 
> There were many other small changes to try to improve document wording and clarity, and I thank a number of my colleagues at Alcatel-Lucent for their helpful reviews.
> 
> Overall, Victor and I feel this new version is much improved, and we hope you guys will too. As always, we welcome further comments.
> 
> - Philip
> 
> On 2015-02-18, at 15:57 , internet-drafts@ietf.org wrote:
> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the IPv6 Operations Working Group of the IETF.
>> 
>>       Title           : Some Design Choices for IPv6 Networks
>>       Authors         : Philip Matthews
>>                         Victor Kuarsingh
>>    Filename        : draft-ietf-v6ops-design-choices-04.txt
>>    Pages           : 17
>>    Date            : 2015-02-18
>> 
>> Abstract:
>>  This document presents advice on certain routing-related design
>>  choices that arise when designing IPv6 networks (both dual-stack and
>>  IPv6-only).  The intended audience is someone designing an IPv6
>>  network who is knowledgeable about best current practices around IPv4
>>  network design, and wishes to learn the corresponding practices for
>>  IPv6.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/
>> 
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-04
>> 
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-design-choices-04
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
>> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>