Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 25 Mar 2016 16:46:05 +0100

Le 17/02/2016 10:13, Liubing (Leo) a écrit :
> Hi Dale,
>
> Thanks much for your elaborating explanation. Replies inline.
>
>
>> To clarify, to mitigate the ULA prefix overlap internally after a
>> merger of two internal networks, nothing related to off-site
>> connectivity.  We have had this issue at our site on ipv4 when our
>> healthcare system and campus enterprise network ended up
>> overlapping in 10/8 and needed NAT just to get between the two,
>> completely unrelated to off-site connectivity.  Having first-hand
>> experienced getting burned I hope we can emphasize the risk to
>> avoid poorly chosen ULA prefixes in non-trivial (more than just a
>> CPE) networks.
>
>> I was going to make a similar comment that I initially withheld
>> about section "6.1. Used in Isolated Networks" to which I would
>> claim isolation, though often well-intended in my experience ends
>> up being temporary when it is found that devices later need
>> external software updates, control, logging, or ancillary support
>> systems for which proxying is too hard.
>>
>> If it's not obvious I do not like ULA at all, and I know a lot of
>> the arguments have already been hashed out.  I am hoping that this
>> guidance can at least be clear about the corners that people will
>> (in my mind) inevitably back themselves into so it can be avoided.
>> There's a lot of value getting that out.
>
> [Bing] From your above comments, I read two warnings: 1. Warning
> people that when they use human-friendly/poorly-chosen ULA prefixes,
> it might result in renumbering or ULA-to-ULA NAT if collision happens
> when sites merging.

This is good warning in some contexts which may be dynamic.

In some office medium-scale environments, which are not evolving at the
current speed of markets, there are plans that need to make sense to
successive generations of adminsitrators.

For that to work these address plans need to be simple to understand, to
describe, to communicate, to maintain fixed.  Random addresses make
these plans hard to do.  Human-readable-sense-making identifiers are
often preferred in these plans.

Google choses and sticks to an RFC number in an IPv6 address that they
communicate to a large number of people.  It could have been something
more difficult to remember and more random.

> 2. Warning people that isolation would be probably temporary, when
> connected, they either deal with ULA+PA, or they'll have to let
> NAT/proxy involved.

I agree.

Alex

>
> In current Section 4.1, there is some text discuss the two points a
> bit, but I think the text needs to be tilt up and be put at a more
> noteworthy place in the next version. Thanks for raising these issues
> up.
>
> Best regards, Bing
>
>> Dale
>>
>> _______________________________________________ v6ops mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 25 Mar 2016 17:06:18 +0100

Hi v6opers,

I have a few comments on draft-ietf-v6ops-ula-usage-considerations-05.

>    o  Default Routing: connectivity may be broken if ULAs are used as
>       default route.  [explanation based on RFC7084 and RFC4191].

Well this should really be formulated differently.

In some enterprise networks the ULAs _are_ used as default routes and 
connectivity is ok with Internet ("Enterprise" described in bullet 2 of 
section 4.2.2).  These are not home nets (RFC7084) nor do they use 
RFC4191 "specific routes".

I suggest the following:

o Default Route: a default route is selected when all other routes in
   the routing table can not be matched against the destination address
   of a packet by using a particular IPv6 longest-match method.
   As such, one would expect that ULA addresses be reached by the
   mechanism of default routing as well.  However, in implementation it
   is not clear whether or not ULA addresses are reached through default
   routes, and which ones; the default routing concept does not have a
   distinctor.  As such, connectivity with ULAs through default routes
   may be broken.

Dont expect to reach ULA prefixes through default routes (other than an 
ULA itself if that's the default route), better use specific routes for 
ULAs.

And yes ULAs _are_ used as default routes.

A route is a tuple: [prefix, next-hop address]

A default route is: [::/0, next-hop address]

A ULA used as a default route is: [::/0, ULA]

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 25 Mar 2016 17:11:49 +0100

Hi v6opers,

Contrary to IPv4, on some routers it is mandatory to say "ipv6 
unicast-routing" otherwise routing is not working.  In IPv4 you dont 
have to say that, but in IPv6 yes.

I guess this is a negative side effect of the importance multicast has 
in IPv6.

In a perspective of IPv6 now everywhere, s/IPv6/IP/g in all CLI.

Alex

---

From: joel jaeggli <[email-masked]>
Date: Fri, 25 Mar 2016 09:32:41 -0700

> I guess this is a negative side effect of the importance multicast has

if your user interface conventions for enabling protocols on  a router
are embedded in conventions you came up with in the 80s there are going
to be  few warts.

> In a perspective of IPv6 now everywhere, s/IPv6/IP/g in all CLI.

Not violating the expectations derived for the existing configuration /
convention is something vendors overlook at their peril...

> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Gert Doering <[email-masked]>
Date: Fri, 25 Mar 2016 19:23:55 +0100

Hi,

> I guess this is a negative side effect of the importance multicast has 

This is just a matter of defaults.  Back in the day, you had to turn
on "ip unicast-routing" as well - if not set, the device would be a 
host, not a router (read: not forward packets).

> In a perspective of IPv6 now everywhere, s/IPv6/IP/g in all CLI.

No, because that does not make sense - but s/ip/ipv4/ (as IOS XR does)
is reasonable.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279