Subject: [v6ops] draft-ietf-v6ops-design-choices WGLC

From: [email-masked]
Date: Sun, 12 Apr 2015 11:00:03 -0700

The working group last call for this draft announced last week
continues for another week.  Please feel free to comment on it.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 13 Apr 2015 08:39:55 +0200 (CEST)

> continues for another week.  Please feel free to comment on it.

Re-reading it as if I never read it before:

2.1.2. Regarding using ULAs. I have run into one instance in reality where 
an ISP numbered an interface from ULAs on a VERY popular large router 
vendor device. This meant that PTBs were generated with a ULA source 
address. This is obviously totally broken, and I think text warning about 
this should be added. Numbering interfaces with ULA and LLA only means one 
has to make VERY SURE that PTBs and other ICMP messsages are not sourced 
from these ULA addresses if the intent is to use this outside of a private 
network. I also question how common it is to use ULAs, with current 
wording it seems to indicate that both are quite common, which I don't 
agree with.

2.2.1. I agree with this, so my suggestion is that the ULA reference above 
is removed or severely downplay:ed, otherwise last sentence in 2.2.1 needs 
to say GUA or ULA as next-hop address.

2.3.1. I have personally been involved in running ISIS for IPv4 and OSPFv3 
for IPv6 at the same time (option b), due to IPv6 related ISIS vendor bug. 
I don't see why this wouldn't be known to work well? This isn't something 
I feel strongly about though...

Apart from these relatively small points above, I think this document is 
in good shape, useful, and ready to proceed.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 14 Apr 2015 00:34:09 +0000 (UTC)

From: Mikael Abrahamsson <[email-masked]>
 To: [email-masked] 
 Sent: Monday, 13 April 2015, 16:39
 Subject: Re: [v6ops] draft-ietf-v6ops-design-choices WGLC

network.

/ RFC6752, "Issues with Private IP Addressing in the Internet" is on this topic, although it is only discussing IPv4 private addressing, and is discussing the case where there is only private/RFC1918 addressing on the link, not the where if you're going to be generating PTBs for network external devices, you source addresses that are valid outside your network i.e. PTB source loopback assigned or on-link GUAs in addition to ULAs.
/ A generalised IPv4 and IPv6 version of RFC6752 would be useful, however in the mean time, in this draft, that one could be referenced, with a couple of paragraphs highlighting that while similar problems could occur with IPv6, that RFC is assuming just a single private addressing prefix on the link and that the alternative is a single public addressing prefix on the link, where as IPv6 fully supports concurrent private and public prefix on a link.

 I also question how common it is to use ULAs, with current 
wording it seems to indicate that both are quite common, which I don't 
agree with.

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: JF Tremblay <[email-masked]>
Date: Tue, 14 Apr 2015 10:53:31 -0400

> On Apr 13, 2015, at 2:39 AM, Mikael Abrahamsson <[email-masked]> wrote:
> 
> 2.1.2. Regarding using ULAs. I have run into one instance in reality where an ISP numbered an interface from ULAs on a VERY popular large router vendor device. This meant that PTBs were generated with a ULA source address. This is obviously totally broken, and I think text warning about this should be added.

+1 on this, a warning regarding PTB would be a good addition. I’ve seen this happen in an early 6RD deployment where ULAs were present on the relay. In that case, you almost have to add GUAs to every single interface where ULAs are present, as it can be hard to predict from which source the PTB will be generated.   

The limitation of using ULAs could be outlined better in this section (2.1.2), as they seem to be lumped together with GUAs in option b.

> I also question how common it is to use ULAs, with current wording it seems to indicate that both are quite common, which I don't agree with.

- Which part of the text indicates this? I read this again, but I must have missed it.. 

- Do you have actual data about ULA usage? As this is isn’t externally visible, one might be surprised at how commonly it is used.  

> 2.2.1. I agree with this, so my suggestion is that the ULA reference above is removed or severely downplay:ed, otherwise last sentence in 2.2.1 needs to say GUA or ULA as next-hop address.

I somewhat agree here. ULA could very well be used as a next-hop, even for a multi-hop route. 

JF

---

From: JF Tremblay <[email-masked]>
Date: Tue, 14 Apr 2015 12:56:01 -0400

> On Apr 12, 2015, at 2:00 PM, [email-masked] wrote:
> 

I’ve read this draft again (previous read was a long time ago) and find it useful for IPv6 implementer, both in an ISP and enterprise environment. In general, it provides advice of good quality, although I found that GUA and ULAs are often lumped together while their usage could/should be differentiated. Sorry if my comments regarding this come a bit late. 

Detailed comments: 
1. In 2.1.1, it might have been clearer to separate “different physical interfaces” vs “different logical interfaces”, therefore having options a, b (vlans) and c (physical). Some of the advantages listed belong to both a and b, with the additional advantage in b that traffic statistics are independent. This is mentioned in the last paragraph, but could be expressed more clearly. I’d argue that (a) is the most attractive option, while b (vlans) could be applied at some specific locations requiring it.  

2. In sections in sections 2.1.2 and 2.2.1 GUAs and ULAs are grouped together in option b. Separating them would allow for finer-grain distinctions.
For example: 
  + Traceroute: using ULAs will allow internal debugging with the proper interfaces, while a traceroute from an external IP might be blocked or be non-useful by leaking ULA information. 
  + DNS: ULAs are likely to having meaning and rDNS information only within the internal network boundary. 
  + In 2.2.1, ULAs are usually suitable for indirect static routes and redistribution, adding a note to this effect would be desirable. 

3. In 2.1.2, I second Mikael’s suggestion to add text around ICMP reachability (especially PTB) when LL or ULA is used on interfaces. Again, separating ULA and GUA would help this. 

4. In 2.3.1, I’ve seen implementations where single topology ISIS had been taken by protocol implementers to mean “IPv4 single-topology”. I’ve met issues running ISIS as single IPv6 topology mode. It might be worth mentioning in a general fashion at the end of the second-last paragraph. (for example s/flexibility/flexibility and stability/). No strong feeling about this one. 

5. Also in 2.3.1 (last sentence): “ISIS is more secure because it runs at layer 2”. Last time I checked, ISIS ran using CLNS, which is an OSI layer-3 protocol. 

6. In the same sentence (last one of 2.3.1): “routers generally support more nodes in an ISIS area”. Any vendor-neutral data to back this? 
My understanding is that area size is, on most devices, CPU-constrained by the SPF calculation. As both IGPs use the same algorithm, one would think that the area limitations would be fairly similar for both protocols. ISIS’s TLVs might be programmatically simpler to process and therefore allow a slightly larger number of nodes/updates for the same processing budget, but I’ve never seen this as significant. I suggest dropping this whole sentence. 

7. Section 2.4.1.1, second bullet, refers to “note 1 above”. I guess this is the second bullet of 2.4.1, but this could be made clearer. 

JF

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 15 Apr 2015 15:37:08 +0200 (CEST)

On Tue, 14 Apr 2015, JF Tremblay wrote:

>> I also question how common it is to use ULAs, with current wording it 
>> seems to indicate that both are quite common, which I don't agree with.
>

Last sentence of 2.1.2. "Today, most operators use interfaces with global 
or unique-local addresses (option b)."

> - Do you have actual data about ULA usage? As this is isn’t externally visible, one might be surprised at how commonly it is used.

Nope, I do not, I commonly see links numbered with interface-unique GUA, I 
have not commonly seen * * * or ULA packets in traceroute.

---

From: JF Tremblay <[email-masked]>
Date: Wed, 15 Apr 2015 15:34:42 -0400

> On Apr 15, 2015, at 9:37 AM, Mikael Abrahamsson <[email-masked]> wrote:
> 
> Last sentence of 2.1.2. "Today, most operators use interfaces with global or unique-local addresses (option b).”

Ah! That might be one more reason to split this one in a, b and c. 

> Nope, I do not, I commonly see links numbered with interface-unique GUA, I have not commonly seen * * * or ULA packets in trace route.

Fair enough. Might not cover cases where propagate-ttl is disabled or when ULA is used off-path, but it’s a valid observation. 

JF

---

From: joel jaeggli <[email-masked]>
Date: Wed, 15 Apr 2015 12:56:23 -0700

> Fair enough. Might not cover cases where propagate-ttl is disabled or when ULA is used off-path, but it’s a valid observation. 

In general  I would expect responsible ISPs and end sites to filter ULA
sourced packets on ingress as they do RFC 1918 to prevent their use in
spoofing.

our recommendations with respect to accepting such prefixes as
advertisements from a peer are in

https://tools.ietf.org/html/rfc7454#section-6.1.1

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 16 Apr 2015 03:11:13 +0000 (UTC)

From: JF Tremblay <[email-masked]>
 To: v6ops list <[email-masked]> 
 Sent: Thursday, 16 April 2015, 5:34
 Subject: Re: [v6ops] draft-ietf-v6ops-design-choices WGLC

/ IPv6 src/dest selection rules should be hiding ULAs from you when you're external to networks that are using both GUAs and ULAs. i.e., if your source address is a GUA, then the traceroute ICMP messages should be using GUA source addresses rather than ULAs if they're available. ULAs should only be leaking if there is no GUA to use and packets with ULA source addresses aren't being blocked at the ULA numbered network's boundary, contrary to good internal/private address practices.
/ ULAs shouldn't be very visible on the Internet because that is the point of them, they're meant for internal use only. So, as the saying goes, "absence of evidence is not evidence of absence."
/Regards,/Mark.

JF

---

From: JF Tremblay <[email-masked]>
Date: Thu, 16 Apr 2015 09:27:55 -0400

> / IPv6 src/dest selection rules should be hiding ULAs from you when you're external to networks that are using both GUAs and ULAs. i.e., if your source address is a GUA, then the traceroute ICMP me…

That was Mikael’s point. Stars (***) in a traceroute might be an externally-visible indication of filtered ULAs sources. But he was arguing he hasn’t seen it often, which is a valid data point. 

> / ULAs shouldn't be very visible on the Internet because that is the point of them, they're meant for internal use only. So, as the saying goes, "absence of evidence is not evidence of absence.”

My point exactly, thanks for the better wording. If, for example, P routers in an MPLS network are numbered in ULA (I’ve done this) and do not decrease TTL, they will not show up at all in traceroutes. 

JF