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

[Mark ZZZ Smith <[e-mail]>]

Hi Philip,


----- Original Message -----
From: Philip Matthews <[e-mail]>
To: Mark ZZZ Smith <[e-mail]>
Cc: v6ops list <[e-mail]>
Sent: Tuesday, 10 March 2015, 6:05
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt

Hi Mark:

Thanks very much for your comments!   We have adopted some of your proposals, but not quite everything.

We have adopted your proposed re-wording for the third paragraph (with a few minor re-wordings).

You proposed to eliminate all uses of the term "unnumbered interface" and replace it with "interface with only link-local address".  We feel this is too extreme, but we now alternate between the two forms and make it very clear that the two terms means the same thing.


/ The concern I have with continuing to use an incorrect term, even though it might be fairly commonly used, is that the longer it is used, the longer it can cause confusion or error, and the longer it encourages the use of the inaccurate term.

/ Somebody who knows very little about IPv6 (which might be a reasonable portion of the audience of your document) would assume an 'unnumbered' link would have no IPv6 addressing present at all on any of the attached interfaces, because that is the case with IPv4. That misunderstanding can have security implications, as unnumbered IPv4 links can't by default support IPv4 applications if hosts are attached to the IPv4 unnumbered link, where as 'unnumbered' IPv6 links can (because they're not actually unnumbered).

/ Another point of confusion would be that in IPv4, unnumbered links are usually only serial point-to-point links between routers, meaning that hosts can't physically be attached to the link, where as any type of link can be an IPv6 "unnumbered" link, so hosts may be physically attached to the link if the link-layer is multi-access.

/ These subtle yet significant differences are the ones that, if hidden by incorrect terminology, create opportunities for security or operational problems. In my experience avoiding those issues is far cheaper and easier than cleaning up after they've occurred.

/ I think in your document it would be better to use the term 'link-local only' throughout the document, and just acknowledge once early in the document that it has been also described as 'unnumbered' as it is somewhat similar to the IPv4 concept of unnumbered link, but certainly isn't the same.


We have some concerns with your proposed rewording for the first and second paragraphs.  In version -04, we narrowed the scope of the draft to routing-related design choices.

/ So I think the title needs to reflect that e.g., "Some Design Choices for IPv6 Routing"

 One of the minor changes introduced at this time was a rename of section 2.1 to "Interfaces" from "Links", and corresponding changes in the section body: interfaces being a layer 3 concept, while links are a layer-2 concept. This we don't want to change the text back to read "links".

/ I don't agree with "interfaces being a layer 3 concept", and I think if you think a bit more about it you wouldn't either.

/ My perspective is that documents such as this one should be written to address the issues and topics covered from the most common perspective or point of view the audience is likely to have. People 'assign' prefixes to links when they're planning addressing, even though in practice the prefixes are implicitly assigned to a link via addresses assignment to device interfaces. You can see examples of this perspective throughout RFC5375 and many other documents or books that cover IPv6 addressing, and in my experience it is a common perspective.

We also feel that the use of SLAAC or DHCP to assign global addresses to router interfaces is very uncommon on networks that people actually design (as opposed to ad-hoc or home networks).

/ I'm a bit confused by this. If this is referring to this bit of text I suggested below,

"Note that although it is not required, it is common and likely that the attached nodes' link-attached interfaces will have addresses from all of the present GUA and/or ULA prefixes, as the nodes will be likely to automatically participate in the SLAAC and/or stateful DHCPv6 address configuration protocols."



I should have written "hosts" rather than "nodes" i.e.,

"Note that although it is not required, it is common and likely that the attached hosts' link-attached interfaces will have addresses from all of the present GUA and/or ULA prefixes, as the hosts will be likely to automatically participate in the SLAAC and/or stateful DHCPv6 address configuration protocols."

Hopefully you are content with what we did. If not, perhaps we can discuss face-to-face in Dallas.

/ I won't be at the IETF in Dallas unless somebody was willing to sponsor my attendance.


Regards,
Mark.


- Philip

On 2015-02-23, at 4:01 , Mark ZZZ Smith wrote:

> Hi Philip,
> 
> 
> ----- Original Message -----
> From: Philip Matthews <[e-mail]>
> To: Mark ZZZ Smith <[e-mail]>
> Cc: v6ops list <[e-mail]>
> Sent: Sunday, 22 February 2015, 14:40
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt
> 
> 
> On 2015-02-19, at 23:13 , Mark ZZZ Smith wrote:
> 
>> Hi,
>> 
>> 
>> ----- Original Message -----
>> From: Philip Matthews <[e-mail]>
>> To: Mark ZZZ Smith <[e-mail]>
>> Cc: v6ops list <[e-mail]>
>> 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
>> 
> <snip> 
>> /"Have global and/or unique-local addresses assigned in addition to link-locals" would probably read better.
> DONE
> 
> /There is a loose ')' in there though ;-)
> 
>> 
>> /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. 
> 
> Interesting comment.  However, I confess that I am not seeing how this section might be rewritten.  Note that this section is just trying to contrast zero vs non-zero numbers of GUAs and/or ULAs, and not discuss one vs two vs ... GUAs/ULAs.
> 
> / I understand what it is trying to contrast, and I'd describe it as contrasting whether to have just a link-local prefix on the link, or whether to add one or more GUA and/or ULA prefixes to the link. 
> 
> / If that description is correct, then it is assuming that all interfaces attached to the link will get addresses from what ever prefixes are present on the link. Yet the text, by being 'Interface' oriented', rather than 'link oriented' implies that it is a decision that would be made on a per-interface rather than a per-link basis. Technically it can be made on a per-Interface basis, but commonly isn't.
> 
> Perhaps you could give an example or two of rewritten sentences?
> 
> / How about something like this:
> 
> 2.1.2. Link-local prefix only links?
> 
> The Link-local prefix is automatically present on links on which IPv6 is operating over, as all IPv6 interfaces are required to have a Link-Local address [RFC4291]. Link-local addresses are or can be used for IPv6 operation or applications when the source and destination are on-link [RFC4007][RFC5942][RFC6724]
> 
> To provide on-link nodes with the ability to reach off-link destinations, or for off-link sources to reach on-link destinations, one or more GUA and/or ULA prefixes need to be present on the link. Note that although it is not required, it is common and likely that the attached nodes' link-attached interfaces will have addresses from all of the present GUA and/or ULA prefixes, as the nodes will be likely to automatically participate in the SLAAC and/or stateful DHCPv6 address configuration protocols.
> 
> There are two advantages of interfaces that only have Link-Local addresses.  The first
> advantage is ease of configuration.  In a network with a large number
> of Link-Local only interfaces, the operator can just enable an IGP on each
> router, without going through the tedious process of assigning and
> tracking the addresses for each interface.  The second advantage is
> security.  Since packets with Link-Local destination addresses should
> not be routed, it is very difficult to attack the associated
> nodes from an off-link device.  This implies less effort around
> maintaining security ACLs.
> 
> (etc.)
> 
> 
> Regards,
> Mark.
> 
>> 
>> 
>> 
>>> 
>>> "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 <[e-mail]>
>>> To: v6ops list <[e-mail]>
>>> 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 , [e-mail] 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>> 
>> 
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>> 
> 
> 
> 
>> 
>> 
>> 
>>> 
>>> "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 <[e-mail]>
>>> To: v6ops list <[e-mail]>
>>> 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 , [e-mail] 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>> 
>> 
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>> 
>