IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks)

Fri Mar 2 14:55:26 UTC 2018

> On Mar 2, 2018, at 19:25, Bjørn Mork <bjorn at mork.no> wrote:
> 
> Owen DeLong <owen at delong.com> writes:
> 
>>> On Mar 2, 2018, at 3:17 AM, Bjørn Mork <bjorn at mork.no> wrote:
>>> 
>>> Owen DeLong <owen at delong.com> writes:
>>> 
>>>> What can you do with ULA that GUA isn’t suitable for?
>>> 
>>> 1) get
>>> 2) keep
>>> 3) move
>> 
>> Wrong.
>> 
>> 1) get
>>    Easy as going to http://tunnelbroker.net <http://tunnelbroker.net/> and filling out a form. Remember to check the box for your /48.
> 
> Provided you have IPv4 connectivity and an email address you can and
> will associate with the tunnel/prefix.  You are limiting the scope here.
> 

Having an email address is a pretty low bar. You don’t need to actually set up the tunnel, so all you need is an ipv4 address that answers Icmp echo. Also not hard to come by. 

>> 2) keep
>>    Admittedly, you might have to connect to your tunnel every once in a while to keep it alive, but that’s
>>    hardly a high bar.
> 
> Depends.  How about preconfigured devices in storage?  There are a
> number of use cases where outside connectivity does not matter, and
> where depending on regular connections will complicate stuff.

You don’t have to connect from the devices using the addresses, you just need to connect. A simple laptop will do. 

> 
>> 3) move
>>    If you’re not talking to the internet with it (which you can’t with ULA, theoretically), you can move that same
>>    HE /48 anywhere you want, with the additional advantage that you can, if you need to, connect your tunnel
>>    and actually make it work on the internet too.
> 
> Sure. There is also a long tradition in IPv4 for "borrowing" someone
> elses addresses.  It is never a good idea.  You or anyone else cannot
> make any guarantee about HE address availability at any point in time or
> space.

Meh... if you’re concerned about that, get the addresses from an RIR. Some people think $100/year is a barrier, so I proposed a free alternative. 
> 
> You may also want to consider https://www.tunnelbroker.net/tos.php

Last time I read it, it didn’t preclude what I’m suggesting. It may have been updated, but if it was, I bet there are still workarounds within the TOS. 

> 
> 
>>> Granted, many of us can do that with GUAs too.  But with ULA those
>>> features are avaible to everyone everywhere.  Which is useful for a
>> 
>> You really think that doing ULA according to the RFCs (collision
>> avoidance algorithm and all) is easier than filling out a form at HE?
>> REALLY?
> 
> Yes.
> 
> You are comparing apples and orange seeds.  If you don't want to
> construct your tunnel from the RFCs, then you cannot require ULA users
> to start there either,

I wasn’t proposing actually constructing a tunnel at all. Merely using the tunnel as a way to get a /48 for free. 

I wasn’t requiring the Ilan user to start from the RFCs, but specifying that the had to comply with them. 

The calculator is a slightly shorter form, I’ll grant you, but it doesn’t strike me as substantially easier. 

> 
> The ULA equivalent of the HE tunnel form is an ULA calculator. E.g
> http://www.kame.net/~suz/gen-ula.html
> 
> Which is much simpler.  At least it looks simpler to me.
> 
> But it doesn't really matter.  The main point is that ULAs are usable in
> many cases where HE (or other ISP allocated) GUAs are not. If you don't
> care about Internet connectivity, then ULAs are as good as PI GUA space.

My point is that in that case GUA is as good as ULA too. ULA offers no advantage. It’s just a waste of a /7. 

> 
> Believe it or not, but there are still devices and networks where
> Internet connectivity is either optional or even unwanted.  These
> devices and networks still need addresses for their internal
> communcation.

Never denied that. I have some at home. They have /64s carved out of my /48 and work just fine. 

> 
>>> number of applications where you care mostly about the local environment
>>> and not so much about global connectivity.
>> 
>> I hear you, but I’m not convinced about the ease.
> 
> When was the last time you saw a non RFC1918 address in a consumer
> equipment setup guide?  If we consider the distant future where IPv4 is
> long dead and buried, what is default configuration URL is going to
> replace http://192.168.1.1/ and similar?

One would home something less brain-dead like http://config.local

If your asking about what prefix should be used in examples, well, that’s what we have 2001:db8::/32 for. 

> 
> IoT might be a thing for a while until people start worrying about where
> they store their data.  I'm sure local sensor networks will become
> popular again once the hype is over.
> 
> Many ISPs make more money on providing network accesses which are
> isolated from the Internet than actually providing Internet access
> 
> More and more systems are made up of networked subsystems.  Take a look
> at your average core router for example. These susbsystems need
> addresses.  But you rarely want them to connect to the Internet.
> 
> One can easily imagine future PC or handheld systems where internal
> buses like I2C and USB (when used to connect *internal* lowspeed
> components like fingerprint readers etc) have been replaced by IP over
> ethernet.
> 
> Just to name a few applications I can think of here and now.  There are
> many many more.

Sure, and there’s no disadvantage whatsoever from using GUA to address these. 
> 
> I'm not claiming that ULAs are the answers to all these.  There are
> certainly reasons why you might want GUAs instead.  But these are cases
> where the main disadvantage of the ULAs - The lack of Internet
> connectivity - does not matter, or is even turned into an advantage.

I don’t see it ever being an advantage, but I agree there are situations where that particular property isn’t a disadvantage. I never denied that. Still there’s no actual advantage to ULA... it’s just a convenient way to completely waste a /8 and mostly waste another /8. 

Owen

> 
> 
> 
> 
> Bjørn