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

Regarding these text about link-local only links:

"o  On some devices, by default the link-layer address of the
interface is derived from the MAC address assigned to interface.
When this is done, swapping out the interface hardware (e.g.
interface card) will cause the link-layer address to change.  In
some cases (peering config, ACLs, etc) this may require additional
changes.  However, many devices allow the link-layer address of an
interface to be explicitly configured, which avoids this issue."

And other similar text about LLs being derived from MAC addresses,

I think it is worth referencing RFC7217, "A Method for Generating Semantically Opaque Interface Identifiers
with IPv6 Stateless Address Autoconfiguration (SLAAC)", as one of the use cases it is intended to address is the case of interface swaps changing SLAAC addresses, which includes link-local addresses, as they're SLAAC addresses. (See Appendix A of RFC7217)
 Actually, I think it would be better to stop using "Unnumbered Interfaces"/"Unnumbered Links" because factually it is incorrect in IPv6. Something like "Link-Local Only Interfaces" would be better, and encourage people to remembering that link-local addresses are always present in IPv6. (and perhaps start to get people into the mindset that link-locals may also be used for application traffic too, as per RFC4007 and RFC6724)

----- 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