RE: IPv6 Unique Local Addresses

[Nicholas Warren]

Please don't take away ULA.

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

It's hard enough to sell ipv6 for LAN without adding having to get a tunnel, 
register with a RIR, whatever else.

ULA gives us the option to spin up ipv6 networks without anyone else being 
involved. We have to be able to make private networks without contacting 
anyone, and we will go back to ipv4 if that's our only option.

Comcast NOC Contact

[Robert Webb]

I know Virginia is having wind issues today. But can anyone from Comcast 
comment on intermittent routing issues between Charlottesville, VA and Ashburn, 
VA on their backbone?

Issue appears to be between 69.139.206.9 
ae-45-ar02.charlvilleco.va.ibone.comcast.net and 68.86.91.53 
be-21508-cr02.ashburn.va.ibone.comcast.net

Off list is fine.

Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks

[Stephen Satchell]

On 03/01/2018 02:55 PM, Royce Williams wrote:

pstream, until two days ago, the default was to listen on all interfaces.

https://github.com/memcached/memcached/wiki/ReleaseNotes156

The package maintainers were (thankfully) injecting additional sanity.


Yes, they did, in commit dbb7a8af.  Here is the commit comment:


disable UDP port by default

As reported, UDP amplification attacks have started to use insecure

internet-exposed memcached instances. UDP used to be a lot more popular as a
transport for memcached many years ago, but I'm not aware of many recent
users.

Ten years ago, the TCP connection overhead from many clients was relatively

high (dozens or hundreds per client server), but these days many clients are
batched, or user fewer processes, or simply anre't worried about it.

While changing the default to listen on localhost only would also help, the

true culprit is UDP. There are many more use cases for using memcached over
the network than there are for using the UDP protocol.

- memcached.c -
index 88a5f2e..7178666 100644


But then you look at the changes in that commit:  what makes this a 
less-than-ideal change is that they didn't modify the default 
configuration file to include "-U 0".


By defaulting their settings.udpport to zero in the C code, they 
stop-punch the astonishment factor.  By not changing the distribution 
sysconfig file, though, they open a pitfall for those people who use 
UDP.  The problem?  They could have put a warning in the default file so 
that people who add OPTIONS="U 11211" would be told to firewall that UDP 
port from the public internet at large.


(Then there is the case of people deploying memcached in the cloud, 
which would incur additional difficulties.  But that's another argument...)

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG, CaribNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 03 Mar, 2018

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  687961
Prefixes after maximum aggregation (per Origin AS):  266895
Deaggregation factor:  2.58
Unique aggregates announced (without unneeded subnets):  331711
Total ASes present in the Internet Routing Table: 59983
Prefixes per ASN: 11.47
Origin-only ASes present in the Internet Routing Table:   51808
Origin ASes announcing only one prefix:   22740
Transit ASes present in the Internet Routing Table:8175
Transit-only ASes present in the Internet Routing Table:257
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  37
Max AS path prepend of ASN (262865)  25
Prefixes from unregistered ASNs in the Routing Table:58
Number of instances of unregistered ASNs:58
Number of 32-bit ASNs allocated by the RIRs:  21677
Number of 32-bit ASNs visible in the Routing Table:   17438
Prefixes from 32-bit ASNs in the Routing Table:   72349
Number of bogon 32-bit ASNs visible in the Routing Table:10
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:326
Number of addresses announced to Internet:   2855228258
Equivalent to 170 /8s, 47 /16s and 83 /24s
Percentage of available address space announced:   77.1
Percentage of allocated address space announced:   77.1
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   98.8
Total number of prefixes smaller than registry allocations:  228105

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   189669
Total APNIC prefixes after maximum aggregation:   54076
APNIC Deaggregation factor:3.51
Prefixes being announced from the APNIC address blocks:  188647
Unique aggregates announced from the APNIC address blocks:77563
APNIC Region origin ASes present in the Internet Routing Table:8675
APNIC Prefixes per ASN:   21.75
APNIC Region origin ASes announcing only one prefix:   2459
APNIC Region transit ASes present in the Internet Routing Table:   1284
Average APNIC Region AS path length visible:4.3
Max APNIC Region AS path length visible: 27
Number of APNIC region 32-bit ASNs visible in the Routing Table:   3589
Number of APNIC addresses announced to Internet:  768016418
Equivalent to 45 /8s, 199 /16s and 0 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-137529
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:205098
Total ARIN prefixes after maximum aggregation:98253
ARIN Deaggregation factor: 2.09
Prefixes being announced from the ARIN address blocks:   205932
Unique aggregates announced from the ARIN address blocks: 97158
ARIN Region origin ASes present in the Internet Routing Table:18084
ARIN Prefixes per ASN:  

Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks

[Stephen Satchell]

Testing on a recently-load VM of CentOS 7.3:

[root@localhost odd]# netstat -tan | grep 11211
[root@localhost odd]# netstat -uan | grep 11211
[root@localhost odd]# yum install memcached
[root@localhost odd]# systemctl start memcached.service
[root@localhost odd]# netstat -tan | grep 11211
tcp0  0 0.0.0.0:11211   0.0.0.0:*   LISTEN
tcp6   0  0 :::11211:::*LISTEN
[root@localhost odd]# netstat -uan | grep 11211
udp0  0 0.0.0.0:11211   0.0.0.0:* 

udp6   0  0 :::11211:::* 



Since CentOS is supposed to be a near bit-by-bit copy of Red Hat 
Enterprise, this shows that when one loads memcached without modifying 
the configuration, plus expose 11211/udp to the world, one is now part 
of the problem.


It also suggests that other near-clones of RHEL may also exhibit the 
problem.


So I pulled the memcached repository from GitHub, and looked through the 
commits. NOTHING about updates to prevent DDoS.


So I started looking around for the config file in the maintainer GIT 
project.  Here is what I found:



# These defaults will be used by every memcached instance, unless overridden
# by values in /etc/sysconfig/memcached.
USER="nobody"
MAXCONN="1024"
CACHESIZE="64"
OPTIONS=""

# The PORT variable will only be used by memcached.service, not by
# memcached@x services, which will use the x
PORT="11211"


Here is what CentOS has:


PORT="11211"
USER="memcached"
MAXCONN="1024"
CACHESIZE="64"
OPTIONS=""


What's missing from both of these system configuration files?

OPTIONS="-U 0"

From the memcached man page:


-U 
   Listen on UDP port , the default is port 11211, 0 is off.


So this answers the question about how anyone loading memcached fresh 
from a distribution can be a major player in the DDoS game.


Now, in a lame defense of Red Hat, when one turns on the firewalld 
daemon, that daemon implements a mostly-closed access policy. 
"memcached" is not listed in the named services.  Furthermore, looking 
at the output of 'iptables -vnL' I saw no way that a 11211/udp packet 
would make its way through the firewall.


The policy of "defense in depth" would argue that setting the default to 
disable 11211/udp is still the right thing(r) to do.

Re: IPv6 Unique Local Addresses

[Owen DeLong]

> On Mar 2, 2018, at 7:55 AM, Nicholas Warren  wrote:
> 
> Please don't take away ULA.
> 
>>> 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.
> 
> It's hard enough to sell ipv6 for LAN without adding having to get a tunnel, 
> register with a RIR, whatever else.
> 
> ULA gives us the option to spin up ipv6 networks without anyone else being 
> involved. We have to be able to make private networks without contacting 
> anyone, and we will go back to ipv4 if that's our only option.

I doubt anyone is taking it away, pointless and useless as it is.

Owen

RE: Comcast NOC Contact

[Robert Webb]

Thanks to all off list replies.

Comcast rep was able to help out getting info over to the NOC.

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Robert Webb
Sent: Friday, March 2, 2018 10:53 AM
To: nanog@nanog.org
Subject: Comcast NOC Contact

I know Virginia is having wind issues today. But can anyone from Comcast 
comment on intermittent routing issues between Charlottesville, VA and Ashburn, 
VA on their backbone?

Issue appears to be between 69.139.206.9 
ae-45-ar02.charlvilleco.va.ibone.comcast.net and 68.86.91.53 
be-21508-cr02.ashburn.va.ibone.comcast.net

Off list is fine.

Re: BCP 38 addendum (was: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks)

[Mike Hammett]

https://en.wikipedia.org/wiki/Reverse_path_forwarding#Loose_mode towards 
transit. 

https://en.wikipedia.org/wiki/Reverse_path_forwarding#Strict_mode towards 
customers. 

Peers... *shrugs*. 



- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Todd Crane"  
To: "NANOG list"  
Cc: "Job Snijders"  
Sent: Thursday, March 1, 2018 12:57:53 PM 
Subject: BCP 38 addendum (was: New Active Exploit: memcached on port 11211 UDP 
& TCP being exploited for reflection attacks) 

Question: 
Since we cannot count on everyone to follow BCP 38 or investigate their abuse@, 
I was thinking about the feasibility of using filtering to prevent spoofing 
from peers’ networks. 

With the exception of a few edge cases, would it be possible to filter inbound 
traffic allowing only packets with source addresses matching the peer’s BGP 
announcement? Theoretically it should be a two way street to any address I can 
receive from, thus if I can’t send to it, I shouldn't be receiving from it. I 
realize this is not currently a feature of any router (to my knowledge), but 
could it be implemented into some NOSs fairly easily and jerry-rigged into 
others for the time being. 

This would allow us to peer with OVH et al, and not worry as much. Furthermore, 
whereas BCP 38 is reliant upon everybody, this could significantly reduce 
amplification attacks with even just a handful of adopters. 


—Todd 

> On Feb 28, 2018, at 6:52 PM, Job Snijders  wrote: 
> 
> On Tue, Feb 27, 2018 at 09:52:54PM +, Chip Marshall wrote: 
>> On 2018-02-27, Ca By  sent: 
>>> Please do take a look at the cloudflare blog specifically as they 
>>> name and shame OVH and Digital Ocean for being the primary sources 
>>> of mega crap traffic 
>>> 
>>> https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/
>>>  
>>> 
>>> Also, policer all UDP all the time... UDP is unsafe at any speed. 
>> 
>> Hi, DigitalOcean here. We've taken steps to mitigate this attack on 
>> our network. 
> 
> NTT too has deployed rate limiters on all external facing interfaces on 
> the GIN backbone - for UDP/11211 traffic - to dampen the negative impact 
> of open memcached instances on peers and customers. 
> 
> The toxic combination of 'one spoofed packet can yield multiple reponse 
> packets' and 'one small packet can yield a very big response' makes the 
> memcached UDP protocol a fine example of double trouble with potential 
> for severe operational impact. 
> 
> Kind regards, 
> 
> Job 

Re: dnswl.org contact

[Matthias Leisi]

> Am 02.03.2018 um 00:55 schrieb Randy Bush :
> 
> anyone have contact with the dnswl.org folk?

replied off-list.

— Matthias

Re: BCP 38 addendum

[joel jaeggli]

On 3/1/18 10:57 AM, Todd Crane wrote:
> Question:
> Since we cannot count on everyone to follow BCP 38 or investigate their 
> abuse@, I was thinking about the feasibility of using filtering to prevent 
> spoofing from peers’ networks.
>
> With the exception of a few edge cases, would it be possible to filter 
> inbound traffic allowing only packets with source addresses matching the 
> peer’s BGP announcement?  Theoretically it should be a two way street to any 
> address I can receive from, thus if I can’t send to it, I shouldn't be 
> receiving from it. I realize this is not currently a feature of any router 
> (to my knowledge), but could it be implemented into some NOSs fairly easily 
> and jerry-rigged into others for the time being.
you can build ACLs from IRR objects  just like you can build prefix
lists. for customers this is just as feasible as controlling what routes
you accept from them.

unlike URPF strict  this will not cause an outage every time a prefix is
withdrawn but traffic continues to flow (which is a normal and healthy
part of doing maintenance).

on the other hand it means your prefix lists will have to be rather up
to date and your peers will likely have to be very up to date with their
customers. since failures for inclusion will cause black holes.

you can't do this on on and MLPE exchange where you export routes unless
you want to cause an outage everytime a new peer is added.

there is also the problem of the number of cam slots these IP acls chew up.

bgpq3 -P AS-FOO
> This would allow us to peer with OVH et al, and not worry as much. 
> Furthermore, whereas BCP 38 is reliant upon everybody, this could 
> significantly reduce amplification attacks with even just a handful of 
> adopters.
The source addresses of attack traffic associated with for example
memcached (and in fact virtually all reflection attacks) are not spoofed.
>
> —Todd
>
>> On Feb 28, 2018, at 6:52 PM, Job Snijders  wrote:
>>
>> On Tue, Feb 27, 2018 at 09:52:54PM +, Chip Marshall wrote:
>>> On 2018-02-27, Ca By  sent:
 Please do take a look at the cloudflare blog specifically as they
 name and shame OVH and Digital Ocean for being the primary sources
 of mega crap traffic

 https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/

 Also, policer all UDP all the time... UDP is unsafe at any speed.
>>> Hi, DigitalOcean here. We've taken steps to mitigate this attack on
>>> our network.
>> NTT too has deployed rate limiters on all external facing interfaces on
>> the GIN backbone - for UDP/11211 traffic - to dampen the negative impact
>> of open memcached instances on peers and customers.
>>
>> The toxic combination of 'one spoofed packet can yield multiple reponse
>> packets' and 'one small packet can yield a very big response' makes the
>> memcached UDP protocol a fine example of double trouble with potential
>> for severe operational impact.
>>
>> Kind regards,
>>
>> Job




signature.asc
Description: OpenPGP digital signature

Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks

[Mark Andrews]

Are you insane. ISPs should never use RFC 1918 addresses for stuff that talks 
to their customers.  They have no way of knowing which addresses the customers 
are using.

Traffic from RFC 1918 addresses should be dropped by any sane border router 
which all routers connecting to a ISP are. 

-- 
Mark Andrews

> On 2 Mar 2018, at 22:49, Bjørn Mork  wrote:
> 
> Owen DeLong  writes:
> 
>> I don’t agree that making RFC-1918 limitations a default in any daemon makes 
>> any
>> sense whatsoever.
> 
> +1
> 
> One of the more annoying anti-features I know of in this regard is the
> dnsmasq rebind "protection".  It claims to protect web browsers on the
> LAN against DNS rebind attacks.  But the implementation does not
> consider which adresses are used on the LAN at all.  It simply blocks
> any A record pointing to an RFC1918 address, making a few bogus
> assumptions:
> - IPv4 LAN addresses are selected from RFC1918
> - RFC1918 addresses are never used on the WAN side of a CPE
> - Noone use IPv6 on their LAN
> 
> It's hard to know how many users have been bitten by the first
> one. You'd have to depend on this rebind "protection" in the first
> place, and that would be stupid.
> 
> But the second assumption regularily bites end users when their ISP
> provides some ISP internal service using RFC1918 addresses.  Which of course
> is fine.
> 
> The anti-feature has been enabled by default in OpenWrt for a long time,
> ref https://wiki.openwrt.org/doc/uci/dhcp#all_options , which means that
> there is a large user base having this enabled without knowing.
> 
>> First, there are plenty of LANs out there that don’t use RFC-1918.
>> 
>> Second, RFC-1918 doesn’t apply to IPv6 at all,
> 
> Could you try to explain that to the OpenWrt guys?  Thanks
> 
> 
> 
> Bjørn

BCP 38 addendum (was: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks)

[Todd Crane]

Question:
Since we cannot count on everyone to follow BCP 38 or investigate their abuse@, 
I was thinking about the feasibility of using filtering to prevent spoofing 
from peers’ networks.

With the exception of a few edge cases, would it be possible to filter inbound 
traffic allowing only packets with source addresses matching the peer’s BGP 
announcement?  Theoretically it should be a two way street to any address I can 
receive from, thus if I can’t send to it, I shouldn't be receiving from it. I 
realize this is not currently a feature of any router (to my knowledge), but 
could it be implemented into some NOSs fairly easily and jerry-rigged into 
others for the time being.

This would allow us to peer with OVH et al, and not worry as much. Furthermore, 
whereas BCP 38 is reliant upon everybody, this could significantly reduce 
amplification attacks with even just a handful of adopters.


—Todd

> On Feb 28, 2018, at 6:52 PM, Job Snijders  wrote:
> 
> On Tue, Feb 27, 2018 at 09:52:54PM +, Chip Marshall wrote:
>> On 2018-02-27, Ca By  sent:
>>> Please do take a look at the cloudflare blog specifically as they
>>> name and shame OVH and Digital Ocean for being the primary sources
>>> of mega crap traffic
>>> 
>>> https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/
>>> 
>>> Also, policer all UDP all the time... UDP is unsafe at any speed.
>> 
>> Hi, DigitalOcean here. We've taken steps to mitigate this attack on
>> our network.
> 
> NTT too has deployed rate limiters on all external facing interfaces on
> the GIN backbone - for UDP/11211 traffic - to dampen the negative impact
> of open memcached instances on peers and customers.
> 
> The toxic combination of 'one spoofed packet can yield multiple reponse
> packets' and 'one small packet can yield a very big response' makes the
> memcached UDP protocol a fine example of double trouble with potential
> for severe operational impact.
> 
> Kind regards,
> 
> Job



signature.asc
Description: Message signed with OpenPGP

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

[Matt Erculiani]

Not sure if this is the common thought, but if anyone has a network
which requires static IP assignments, they can probably justify a
request for a /48 from an RIR.  After all, ARIN's requirement for an
end-user IPv6 block is, at minimum: "Justify why IPv6 addresses from
an ISP or other LIR are unsuitable". I would think that ISP
portability would satisfy this requirement, but If I'm wrong, I'm
absolutely open to being corrected on this. But most home users have
no need for static IPs, so the dynamic ISP assignment is perfectly
fine.

I think the tech will advance fast enough that keeping up with an IPv6
route table will be a non-issue. IPv6 adoption is, unfortunately, slow
enough that there will be no issues keeping up, even assuming a "slow"
hardware refresh cycle.

-M

On Thu, Mar 1, 2018 at 5:48 PM, Mark Andrews  wrote:
>
>> On 2 Mar 2018, at 9:28 am, Owen DeLong  wrote:
>>
>>
>>> On Mar 1, 2018, at 1:20 PM, Harald Koch  wrote:
>>>
>>> On 1 March 2018 at 15:18, Owen DeLong >> > wrote:
>>> Second, RFC-1918 doesn’t apply to IPv6 at all, and (fortunately) hardly 
>>> anyone
>>> uses ULA (the IPv6 analogue to RFC-1918).
>>>
>>> Wait. What's the objection to ULA? Is it just that NAT is bad, or is there 
>>> something new?
>>
>> No particular objection, but I don’t see the point.
>>
>> What can you do with ULA that GUA isn’t suitable for?
>>
>> Owen
>
> ULA provide stable internal addresses which survive changing ISP
> for the average home user. Now, I know you can do the same thing
> by going to a RIR and getting a prefix but the RIR’s aren’t setup
> to supply prefixes like that to 10 billion of us.
>
> They are also in a specific range which makes setting filtering
> rules easier for everyone else.
>
> Now I would love it if we could support 100 billion routes in the
> DFZ but we aren’t anywhere near being able to do that which would
> be a requirement for abandoning ULA.  Until them they have there
> place.
>
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>

Re: IPv6 Unique Local Addresses

[Matthew Kaufman]

Exactly what Matt Harris says here... ULA is free. Space obtained from ARIN
is not. You want to discourage someone from doing the right thing, charge a
lot for that.

Matthew Kaufman

On Fri, Mar 2, 2018 at 11:30 AM Matt Harris  wrote:

> On Fri, Mar 2, 2018 at 11:08 AM, Owen DeLong  wrote:
>
> >
> > I doubt anyone is taking it away, pointless and useless as it is.
> >
> > Owen
> >
>
> I'm not sure I'd say it's pointless and useless.  It's free, which gives it
> at least some point/use case, versus IPv6 space obtained from an RIR where,
> at least in ARIN's case, you have fees associated with that.  I'm lucky
> enough to have a /32 from ARIN for the networks I work on, so we're not
> stretched for space or worried about deploying ULA.  For a small
> organization where even a /48 would be a luxury, and with no good native
> IPv6 carriers available locally (still plenty of places like that),
> deploying IPv6 on ULA space may be the stepping stone they need until other
> options become open to them.
>

Re: IPv6 Unique Local Addresses

[Matt Harris]

On Fri, Mar 2, 2018 at 2:45 PM, Owen DeLong  wrote:

> Space from tunnel brokers is also free.
>
> Owen
>

For myriad reasons (added latency, reliability concerns related to relying
on traffic over a connection which doesn't offer an SLA or recourse for
downtime, lack of support on ISP-provided CPE, etc) a tunnel broker
connection may not be a feasible choice for all organizations and
networks.  This brings us back to my previous point.

Re: IPv6 Unique Local Addresses

[Matt Harris]

On Fri, Mar 2, 2018 at 11:08 AM, Owen DeLong  wrote:

>
> I doubt anyone is taking it away, pointless and useless as it is.
>
> Owen
>

I'm not sure I'd say it's pointless and useless.  It's free, which gives it
at least some point/use case, versus IPv6 space obtained from an RIR where,
at least in ARIN's case, you have fees associated with that.  I'm lucky
enough to have a /32 from ARIN for the networks I work on, so we're not
stretched for space or worried about deploying ULA.  For a small
organization where even a /48 would be a luxury, and with no good native
IPv6 carriers available locally (still plenty of places like that),
deploying IPv6 on ULA space may be the stepping stone they need until other
options become open to them.

Re: IPv6 Unique Local Addresses

[Owen DeLong]

Space from tunnel brokers is also free.

Owen

> On Mar 2, 2018, at 12:40 PM, Matthew Kaufman  wrote:
> 
> Exactly what Matt Harris says here... ULA is free. Space obtained from ARIN 
> is not. You want to discourage someone from doing the right thing, charge a 
> lot for that.
> 
> Matthew Kaufman
> 
> On Fri, Mar 2, 2018 at 11:30 AM Matt Harris  > wrote:
> On Fri, Mar 2, 2018 at 11:08 AM, Owen DeLong  > wrote:
> 
> >
> > I doubt anyone is taking it away, pointless and useless as it is.
> >
> > Owen
> >
> 
> I'm not sure I'd say it's pointless and useless.  It's free, which gives it
> at least some point/use case, versus IPv6 space obtained from an RIR where,
> at least in ARIN's case, you have fees associated with that.  I'm lucky
> enough to have a /32 from ARIN for the networks I work on, so we're not
> stretched for space or worried about deploying ULA.  For a small
> organization where even a /48 would be a luxury, and with no good native
> IPv6 carriers available locally (still plenty of places like that),
> deploying IPv6 on ULA space may be the stepping stone they need until other
> options become open to them.

Re: BCP 38 addendum (was: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks)

[Barry Raveendran Greene]

Hi Todd,

What you are describing is uRPF VRF mode. This was phase 3 of the uRPF work. 
Russ White and I worked on it while at Cisco. 

Given that you are setting up prefix filters with your peers, you can add to 
the peering agreement that you will only accept packets whose source addresses 
matches the prefixes sent. 

You then take that BGP session, feed that into a VRF on the interface, and run 
uRPF against that VRF. If a source address does not match, drop. 

If the BGP session adds more routes, those automatically update the VRF “white 
list” for the uRPF. 

It was build to scale. Not sure where it is at in the code or the hardware. Ask 
Cisco.

Barry

PS - So yes, you can do uRPF on your peering sessions. It was coded and 
deployed back in 2006.

> On Mar 1, 2018, at 13:57, Todd Crane  wrote:
> 
> Question:
> Since we cannot count on everyone to follow BCP 38 or investigate their 
> abuse@, I was thinking about the feasibility of using filtering to prevent 
> spoofing from peers’ networks.
> 
> With the exception of a few edge cases, would it be possible to filter 
> inbound traffic allowing only packets with source addresses matching the 
> peer’s BGP announcement?  Theoretically it should be a two way street to any 
> address I can receive from, thus if I can’t send to it, I shouldn't be 
> receiving from it. I realize this is not currently a feature of any router 
> (to my knowledge), but could it be implemented into some NOSs fairly easily 
> and jerry-rigged into others for the time being.
> 
> This would allow us to peer with OVH et al, and not worry as much. 
> Furthermore, whereas BCP 38 is reliant upon everybody, this could 
> significantly reduce amplification attacks with even just a handful of 
> adopters.
> 
> 
> —Todd
> 
>> On Feb 28, 2018, at 6:52 PM, Job Snijders  wrote:
>> 
>> On Tue, Feb 27, 2018 at 09:52:54PM +, Chip Marshall wrote:
>>> On 2018-02-27, Ca By  sent:
 Please do take a look at the cloudflare blog specifically as they
 name and shame OVH and Digital Ocean for being the primary sources
 of mega crap traffic
 
 https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/
 
 Also, policer all UDP all the time... UDP is unsafe at any speed.
>>> 
>>> Hi, DigitalOcean here. We've taken steps to mitigate this attack on
>>> our network.
>> 
>> NTT too has deployed rate limiters on all external facing interfaces on
>> the GIN backbone - for UDP/11211 traffic - to dampen the negative impact
>> of open memcached instances on peers and customers.
>> 
>> The toxic combination of 'one spoofed packet can yield multiple reponse
>> packets' and 'one small packet can yield a very big response' makes the
>> memcached UDP protocol a fine example of double trouble with potential
>> for severe operational impact.
>> 
>> Kind regards,
>> 
>> Job
> 

Re: IPv6 Unique Local Addresses

[Owen DeLong]

Once again, you’re talking about usability of the addresses for internet 
connectivity.

I don’t understand the relevance since we’re talking about a GUA based 
substitute for ULA.

What am I missing?

Owen

> On Mar 2, 2018, at 1:29 PM, Bryan Holloway  wrote:
> 
> Another problem with tunnel brokers is that they are sometimes flagged by 
> content providers as being some sort of "proxy", and consequently won't send 
> you traffic. Notably, Netflix.
> 
> 
> On 3/2/18 3:06 PM, Matt Harris wrote:
>> On Fri, Mar 2, 2018 at 2:45 PM, Owen DeLong  wrote:
>>> Space from tunnel brokers is also free.
>>> 
>>> Owen
>>> 
>> For myriad reasons (added latency, reliability concerns related to relying
>> on traffic over a connection which doesn't offer an SLA or recourse for
>> downtime, lack of support on ISP-provided CPE, etc) a tunnel broker
>> connection may not be a feasible choice for all organizations and
>> networks.  This brings us back to my previous point.

Re: IPv6 Unique Local Addresses

[Matt Harris]

On Sat, Mar 3, 2018 at 12:33 AM, Owen DeLong  wrote:

> Sure… You have to maintain the tunnel or they may reassign/reallocate the
> address. Here’s the reality of that, however:
>
> 1. Unless you care about reaching the customer they reassigned it to from
> your network, you don’t care.
> 2. Using it for ULA in addition to the tunnel isn’t really prohibited by
> that. It’s a gray area, I’ll admit.
> 3. Sure, they can cancel the service at any time, but you get what you
> pay for. It saves you $100/year
> while it lasts.
>
> Owen
>

I'm not sure where you're getting the $100 figure from, ARIN's minimum fee
for an allocation is $250/year (for a /40 or smaller block) on top of
membership fees of $500/yr, so that's $750/yr to get a /48 from the North
American RIR (which is the only one I'm looking at today given that the
context is the nanog list).  Additionally, tunnel providers can and have
shut down permanently at random - SixXS was among the largest providers,
and they shut down operations entirely last year.  So any folks using space
from them had to renumber, either on to another tunnel provider's space, or
to ULA.  Re-numbering has associated costs, which in the case we're
pointing to here, could've been saved had they deployed on ULA space
instead.

Re: IPv6 Unique Local Addresses

[Owen DeLong]

> On Mar 2, 2018, at 1:06 PM, Matt Harris  wrote:
> 
> On Fri, Mar 2, 2018 at 2:45 PM, Owen DeLong  > wrote:
> Space from tunnel brokers is also free.
> 
> Owen
> 
> For myriad reasons (added latency, reliability concerns related to relying on 
> traffic over a connection which doesn't offer an SLA or recourse for 
> downtime, lack of support on ISP-provided CPE, etc) a tunnel broker 
> connection may not be a feasible choice for all organizations and networks.  
> This brings us back to my previous point.  
> 
Again, how is this relevant if you are using the space as if it were ULA?

Owen

Re: IPv6 Unique Local Addresses

[Owen DeLong]

Sure… You have to maintain the tunnel or they may reassign/reallocate the 
address. Here’s the reality of that, however:

1.  Unless you care about reaching the customer they reassigned it to from 
your network, you don’t care.
2.  Using it for ULA in addition to the tunnel isn’t really prohibited by 
that. It’s a gray area, I’ll admit.
3.  Sure, they can cancel the service at any time, but you get what you pay 
for. It saves you $100/year
while it lasts.

Owen

> On Mar 2, 2018, at 1:30 PM, Matthew Kaufman  wrote:
> 
> Section 3 of https://tunnelbroker.net/tos.php 
> 
> 
> It isn't "free". It may be included with a service that is currently 
> available for free, but they aren't providing free address space for an 
> unlimited period.
> 
> Matthew Kaufman
> 
> On Fri, Mar 2, 2018 at 12:45 PM Owen DeLong  > wrote:
> Space from tunnel brokers is also free.
> 
> Owen
> 
>> On Mar 2, 2018, at 12:40 PM, Matthew Kaufman > > wrote:
>> 
>> Exactly what Matt Harris says here... ULA is free. Space obtained from ARIN 
>> is not. You want to discourage someone from doing the right thing, charge a 
>> lot for that.
>> 
>> Matthew Kaufman
>> 
>> On Fri, Mar 2, 2018 at 11:30 AM Matt Harris > > wrote:
>> On Fri, Mar 2, 2018 at 11:08 AM, Owen DeLong > > wrote:
>> 
>> >
>> > I doubt anyone is taking it away, pointless and useless as it is.
>> >
>> > Owen
>> >
>> 
>> I'm not sure I'd say it's pointless and useless.  It's free, which gives it
>> at least some point/use case, versus IPv6 space obtained from an RIR where,
>> at least in ARIN's case, you have fees associated with that.  I'm lucky
>> enough to have a /32 from ARIN for the networks I work on, so we're not
>> stretched for space or worried about deploying ULA.  For a small
>> organization where even a /48 would be a luxury, and with no good native
>> IPv6 carriers available locally (still plenty of places like that),
>> deploying IPv6 on ULA space may be the stepping stone they need until other
>> options become open to them.
> 

Re: IPv6 Unique Local Addresses

[John Osmon]

On Sat, Mar 03, 2018 at 12:38:58AM -0600, Matt Harris wrote:
> I'm not sure where you're getting the $100 figure from, ARIN's minimum fee
> for an allocation is $250/year  [...]

End Users have a different fee structure:
  Annual maintenance fees are $100 for each IPv4 address block, $100 for
  each IPv6 address block, and $100 USD for each ASN assigned to the
  organization. 

If you just have an IPv6 block, it's only $100/year.

Re: IPv6 Unique Local Addresses

[Owen DeLong]

> On Mar 2, 2018, at 10:38 PM, Matt Harris  wrote:
> 
> On Sat, Mar 3, 2018 at 12:33 AM, Owen DeLong  > wrote:
> Sure… You have to maintain the tunnel or they may reassign/reallocate the 
> address. Here’s the reality of that, however:
> 
> 1.Unless you care about reaching the customer they reassigned it to from 
> your network, you don’t care.
> 2.Using it for ULA in addition to the tunnel isn’t really prohibited by 
> that. It’s a gray area, I’ll admit.
> 3.Sure, they can cancel the service at any time, but you get what you pay 
> for. It saves you $100/year
>   while it lasts.
> 
> Owen
> 
> I'm not sure where you're getting the $100 figure from, ARIN's minimum fee 
> for an allocation is $250/year (for a /40 or smaller block) on top of 
> membership fees of $500/yr, so that's $750/yr to get a /48 from the North 
> American RIR (which is the only one I'm looking at today given that the 
> context is the nanog list).  Additionally, tunnel providers can and have shut 
> down permanently at random - SixXS was among the largest providers, and they 
> shut down operations entirely last year.  So any folks using space from them 
> had to renumber, either on to another tunnel provider's space, or to ULA.  
> Re-numbering has associated costs, which in the case we're pointing to here, 
> could've been saved had they deployed on ULA space instead.  
> 

You don’t need an allocation. Get an assignment.

Owen

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

[John Levine]

In article  you write:
>What can you do with ULA that GUA isn’t suitable for?

I have a home network with two segments, one wired and one wireless.
It has IPv6 addresses assigned by my ISP, Spectrum nee TWC, which
probably won't change but who knows, they make no promises.  I have
some servers on my network, like printers, scanners, backup disks, and a
phone TA.  Getting my own /48 would be absurd.  ULAs are just the
ticket.

Re: Peering with abusers...good or bad?

[Job Snijders]

On Sat, 3 Mar 2018 at 01:08, Bryan Holloway  wrote:

>
> On 3/2/18 5:29 PM, Ca By wrote:
> > On Fri, Mar 2, 2018 at 2:13 PM Matthew Petach 
> wrote:
> >
> >> On Tue, Feb 27, 2018 at 4:13 PM, Dan Hollis 
> >> wrote:
> >>> OVH does not suprise me in the least.
> >>>
> >>> Maybe this is finally what it will take to get people to de-peer them.
> >>>
> >>
> >> If I de-peer them, I pay my upstream to carry the
> >> attack traffic.
> >>
> >
> > Your isp will do rtbh
> >
> > Your peers wont
>
>
> Some public IXs support RTBH ... Equinix, DE-CIX, to name two ... PNIs
> is a different story.



Those IX “blackhole” mechanisms are a perverse ineffective method that
exists solely for marketing reasons. If you aren’t blackholing in the
fabric you aren’t blackholing.

Kind regards,

Job

>

Peering with abusers...good or bad?

[Matthew Petach]

On Tue, Feb 27, 2018 at 4:13 PM, Dan Hollis  wrote:
> OVH does not suprise me in the least.
>
> Maybe this is finally what it will take to get people to de-peer them.
>

If I de-peer them, I pay my upstream to carry the
attack traffic.

If I maintain peering with them, the attack traffic is free.

It would seem the economics work the other way around.

It would be more cost effective for me to identify the largest sources
of attacks, and reach out to directly peer with them, to avoid paying
an upstream to carry the traffic, if I'm going to end up throwing it
away anyhow.

Re: Peering with abusers...good or bad?

[Ca By]

On Fri, Mar 2, 2018 at 2:13 PM Matthew Petach  wrote:

> On Tue, Feb 27, 2018 at 4:13 PM, Dan Hollis 
> wrote:
> > OVH does not suprise me in the least.
> >
> > Maybe this is finally what it will take to get people to de-peer them.
> >
>
> If I de-peer them, I pay my upstream to carry the
> attack traffic.
>

Your isp will do rtbh

Your peers wont


> If I maintain peering with them, the attack traffic is free.
>
> It would seem the economics work the other way around.
>
> It would be more cost effective for me to identify the largest sources
> of attacks, and reach out to directly peer with them, to avoid paying
> an upstream to carry the traffic, if I'm going to end up throwing it
> away anyhow.
>

Re: Peering with abusers...good or bad?

[Job Snijders]

On Sat, 3 Mar 2018 at 01:23, Baldur Norddahl 
wrote:

> So I want to buy additional ports at each IX. The slowest speed they offer.
> If I am lucky they have a free 100 Mbps. And then I just announce the
> prefix I want to blackhole. Doesn't matter that the port overloads. I am
> just going to null route the traffic anyway...



Sure, that works. Those are called “choke ports”.

Kind regards,

Job

>

Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks

[K. Scott Helms]

They use separate service flows and layer 3 interfaces (usually) in DOCSIS
networks but they often use the same DNS infrastructure which is why I
piped up.

Scott Helms


On Mar 2, 2018 4:46 PM, "Michel 'ic' Luczak"  wrote:

The ones I know do so on private VLANs (or ATM circuits on DSL) so anyway
unrelated to any client’s address space. Also, french triple play ISPs use
RFC1918 space for IPTV but again isolated of any customer network so
doesn’t really matter.

> On 2 Mar 2018, at 22:18, K. Scott Helms  wrote:
>
> I won't comment on the sanity of doing so, but _many_ service providers
use
> EMTAs, ATAs, and other voice devices over RFC1918 space back to their
core.
>

Average number of ports on OLT cards

[Jean-Francois Mezei]

Quick question: (sanity check).

For a deployment happening now by an incumbent telco (aka: serving large
number of homes), how many GPON ports would it want per each OLT card ?

or more precisely, what sort of range is there for the number of ports
for such a deployment?

(The CRTC in Canada is asking for costing info for 4 port cards, so
wondering if this could be squewing the cost per port if cards today are
generally deployed with say 8 or 16 ports).

As an example of where I am coming from:  Bell Canada claimed that
Juniper E320s  costed $x and had 1 gbps of capacity, which means $x per
gbps of capacity, when in fact, the actual real life capacity with PPPoE
going to L2TP links was about 80gbps, which means $x/80 per gbps, so
significant difference in cost per gbps.

Re: Peering with abusers...good or bad?

[Baldur Norddahl]

So I want to buy additional ports at each IX. The slowest speed they offer.
If I am lucky they have a free 100 Mbps. And then I just announce the
prefix I want to blackhole. Doesn't matter that the port overloads. I am
just going to null route the traffic anyway...

Regards

Baldur

Den 3. mar. 2018 01.12 skrev "Job Snijders" :

On Sat, 3 Mar 2018 at 01:08, Bryan Holloway  wrote:

>
> On 3/2/18 5:29 PM, Ca By wrote:
> > On Fri, Mar 2, 2018 at 2:13 PM Matthew Petach 
> wrote:
> >
> >> On Tue, Feb 27, 2018 at 4:13 PM, Dan Hollis 
> >> wrote:
> >>> OVH does not suprise me in the least.
> >>>
> >>> Maybe this is finally what it will take to get people to de-peer them.
> >>>
> >>
> >> If I de-peer them, I pay my upstream to carry the
> >> attack traffic.
> >>
> >
> > Your isp will do rtbh
> >
> > Your peers wont
>
>
> Some public IXs support RTBH ... Equinix, DE-CIX, to name two ... PNIs
> is a different story.



Those IX “blackhole” mechanisms are a perverse ineffective method that
exists solely for marketing reasons. If you aren’t blackholing in the
fabric you aren’t blackholing.

Kind regards,

Job

>

Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks

[K. Scott Helms]

I won't comment on the sanity of doing so, but _many_ service providers use
EMTAs, ATAs, and other voice devices over RFC1918 space back to their core.

On Fri, Mar 2, 2018 at 4:11 PM, Mark Andrews  wrote:

> Are you insane. ISPs should never use RFC 1918 addresses for stuff that
> talks to their customers.  They have no way of knowing which addresses the
> customers are using.
>
> Traffic from RFC 1918 addresses should be dropped by any sane border
> router which all routers connecting to a ISP are.
>
> --
> Mark Andrews
>
> > On 2 Mar 2018, at 22:49, Bjørn Mork  wrote:
> >
> > Owen DeLong  writes:
> >
> >> I don’t agree that making RFC-1918 limitations a default in any daemon
> makes any
> >> sense whatsoever.
> >
> > +1
> >
> > One of the more annoying anti-features I know of in this regard is the
> > dnsmasq rebind "protection".  It claims to protect web browsers on the
> > LAN against DNS rebind attacks.  But the implementation does not
> > consider which adresses are used on the LAN at all.  It simply blocks
> > any A record pointing to an RFC1918 address, making a few bogus
> > assumptions:
> > - IPv4 LAN addresses are selected from RFC1918
> > - RFC1918 addresses are never used on the WAN side of a CPE
> > - Noone use IPv6 on their LAN
> >
> > It's hard to know how many users have been bitten by the first
> > one. You'd have to depend on this rebind "protection" in the first
> > place, and that would be stupid.
> >
> > But the second assumption regularily bites end users when their ISP
> > provides some ISP internal service using RFC1918 addresses.  Which of
> course
> > is fine.
> >
> > The anti-feature has been enabled by default in OpenWrt for a long time,
> > ref https://wiki.openwrt.org/doc/uci/dhcp#all_options , which means that
> > there is a large user base having this enabled without knowing.
> >
> >> First, there are plenty of LANs out there that don’t use RFC-1918.
> >>
> >> Second, RFC-1918 doesn’t apply to IPv6 at all,
> >
> > Could you try to explain that to the OpenWrt guys?  Thanks
> >
> >
> >
> > Bjørn
>
>

Re: IPv6 Unique Local Addresses

[Matthew Kaufman]

Section 3 of https://tunnelbroker.net/tos.php

It isn't "free". It may be included with a service that is currently
available for free, but they aren't providing free address space for an
unlimited period.

Matthew Kaufman

On Fri, Mar 2, 2018 at 12:45 PM Owen DeLong  wrote:

> Space from tunnel brokers is also free.
>
> Owen
>
> On Mar 2, 2018, at 12:40 PM, Matthew Kaufman  wrote:
>
> Exactly what Matt Harris says here... ULA is free. Space obtained from
> ARIN is not. You want to discourage someone from doing the right thing,
> charge a lot for that.
>
> Matthew Kaufman
>
> On Fri, Mar 2, 2018 at 11:30 AM Matt Harris  wrote:
>
>> On Fri, Mar 2, 2018 at 11:08 AM, Owen DeLong  wrote:
>>
>> >
>> > I doubt anyone is taking it away, pointless and useless as it is.
>> >
>> > Owen
>> >
>>
>> I'm not sure I'd say it's pointless and useless.  It's free, which gives
>> it
>> at least some point/use case, versus IPv6 space obtained from an RIR
>> where,
>> at least in ARIN's case, you have fees associated with that.  I'm lucky
>> enough to have a /32 from ARIN for the networks I work on, so we're not
>> stretched for space or worried about deploying ULA.  For a small
>> organization where even a /48 would be a luxury, and with no good native
>> IPv6 carriers available locally (still plenty of places like that),
>> deploying IPv6 on ULA space may be the stepping stone they need until
>> other
>> options become open to them.
>>
>
>

Re: IPv6 Unique Local Addresses

[Bryan Holloway]

Another problem with tunnel brokers is that they are sometimes flagged 
by content providers as being some sort of "proxy", and consequently 
won't send you traffic. Notably, Netflix.



On 3/2/18 3:06 PM, Matt Harris wrote:

On Fri, Mar 2, 2018 at 2:45 PM, Owen DeLong  wrote:


Space from tunnel brokers is also free.

Owen



For myriad reasons (added latency, reliability concerns related to relying
on traffic over a connection which doesn't offer an SLA or recourse for
downtime, lack of support on ISP-provided CPE, etc) a tunnel broker
connection may not be a feasible choice for all organizations and
networks.  This brings us back to my previous point.

Re: Peering with abusers...good or bad?

[Bryan Holloway]

On 3/2/18 5:29 PM, Ca By wrote:

On Fri, Mar 2, 2018 at 2:13 PM Matthew Petach  wrote:


On Tue, Feb 27, 2018 at 4:13 PM, Dan Hollis 
wrote:

OVH does not suprise me in the least.

Maybe this is finally what it will take to get people to de-peer them.



If I de-peer them, I pay my upstream to carry the
attack traffic.



Your isp will do rtbh

Your peers wont



Some public IXs support RTBH ... Equinix, DE-CIX, to name two ... PNIs 
is a different story.





If I maintain peering with them, the attack traffic is free.

It would seem the economics work the other way around.

It would be more cost effective for me to identify the largest sources
of attacks, and reach out to directly peer with them, to avoid paying
an upstream to carry the traffic, if I'm going to end up throwing it
away anyhow.

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

[Enno Rey]

Hi,

On Thu, Mar 01, 2018 at 09:30:32PM -0500, Harald Koch wrote:
> On 1 March 2018 at 18:48, Mark Andrews  wrote:
> 
> > ULA provide stable internal addresses which survive changing ISP
> > for the average home user.
> 
> 
> Yeah this is pretty much what I'm doing. ULA for stable, internal addresses
> that I can put into the (internal) DNS: ISP prefixes for global routing.
> Renumbering is hard.

as is proper (source|destination) address selection in a sufficiently complex 
environment.
for interest: for a system which must be both globally and internally 
reachable, which address do you put into which DNS?


> 
> All of the objections I've seen to ULA are actually objections to (IPv6)
> NAT, which is why I was confused.

the main objection against ULAs is avoidance of complexity in environments 
where at least some systems need global reach(ability), which applies to pretty 
much all environments nowadays.

best

Enno






> 
> (As it turns out my ISP prefix has been static for years, but I'm too lazy
> to undo all of the work...)
> 
> -- 
> Harald

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Matthias Luft, Enno Rey

===
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
===

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

[Saku Ytti]

Enno et al ULA fans

I could not agree more.

Either you provide your enterprise customers transportable address or
ULA. If you assign and promote them to use your 'PA' address, they
will take your PA address with them when they change operator 10 years
from now, and if you reuse it, these two customers cannot reach each
other. Why? Because anyone who has worked at non-trivial size
enterprise knows that even just finding out what needs to be done, to
renumber internal networks is massively long, expensive and error
prone proposal, there will be tons of documents and scripts in
non-standard locations containing IP addresses punched in.

No matter how well you do your job, you cannot impact how others do,
and you must expect them to continue working as they have in the past,
and you must realise when that poses risk to yourself and protect
yourself from that.

ULA at inside and 1:1 to operator address in the edge is what I've
been recommending to my enterprise customers since we started to offer
IPv6 commercially. Fits their existing processes and protects me from
creating tainted unusable addresses.


On 2 March 2018 at 11:39, Enno Rey  wrote:
> Hi,
>
> On Thu, Mar 01, 2018 at 09:30:32PM -0500, Harald Koch wrote:
>> On 1 March 2018 at 18:48, Mark Andrews  wrote:
>>
>> > ULA provide stable internal addresses which survive changing ISP
>> > for the average home user.
>>
>>
>> Yeah this is pretty much what I'm doing. ULA for stable, internal addresses
>> that I can put into the (internal) DNS: ISP prefixes for global routing.
>> Renumbering is hard.
>
> as is proper (source|destination) address selection in a sufficiently complex 
> environment.
> for interest: for a system which must be both globally and internally 
> reachable, which address do you put into which DNS?
>
>
>>
>> All of the objections I've seen to ULA are actually objections to (IPv6)
>> NAT, which is why I was confused.
>
> the main objection against ULAs is avoidance of complexity in environments 
> where at least some systems need global reach(ability), which applies to 
> pretty much all environments nowadays.
>
> best
>
> Enno
>
>
>
>
>
>
>>
>> (As it turns out my ISP prefix has been static for years, but I'm too lazy
>> to undo all of the work...)
>>
>> --
>> Harald
>
> --
> Enno Rey
>
> ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
> Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902
>
> Handelsregister Mannheim: HRB 337135
> Geschaeftsfuehrer: Matthias Luft, Enno Rey
>
> ===
> Blog: www.insinuator.net || Conference: www.troopers.de
> Twitter: @Enno_Insinuator
> ===



-- 
  ++ytti

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

[Owen DeLong]

> On Mar 2, 2018, at 19:25, Bjørn Mork  wrote:
> 
> Owen DeLong  writes:
> 
>>> On Mar 2, 2018, at 3:17 AM, Bjørn Mork  wrote:
>>> 
>>> Owen DeLong  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  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 

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

[Owen DeLong]

> On Mar 2, 2018, at 1:50 AM, Saku Ytti  wrote:
> 
> Enno et al ULA fans
> 
> I could not agree more.
> 
> Either you provide your enterprise customers transportable address or
> ULA. If you assign and promote them to use your 'PA' address, they
> will take your PA address with them when they change operator 10 years
> from now, and if you reuse it, these two customers cannot reach each
> other. Why? Because anyone who has worked at non-trivial size
> enterprise knows that even just finding out what needs to be done, to
> renumber internal networks is massively long, expensive and error
> prone proposal, there will be tons of documents and scripts in
> non-standard locations containing IP addresses punched in.

This, right here, is inherently the a very good reason NOT to use ULA IMHO.

See, no matter how widely you deploy ULA, those same scripts are still going to 
use
the provider assigned public addresses that work for all the things they care 
about and
not just local connectivity.  Instead, you adopted a false sense of security 
and made
it more confusing when things do get renumbered.

I completely agree that PI is the way to go and that PA was a silly idea whose 
time
is long past. For home users, perhaps PA is OK for a little while longer 
(wouldn’t
make me happy in my home, but I’ve got PI, so whatever other folks want to do
isn’t my problem here).

> No matter how well you do your job, you cannot impact how others do,
> and you must expect them to continue working as they have in the past,
> and you must realise when that poses risk to yourself and protect
> yourself from that.

Which won’t happen with ULA.

> ULA at inside and 1:1 to operator address in the edge is what I've
> been recommending to my enterprise customers since we started to offer
> IPv6 commercially. Fits their existing processes and protects me from
> creating tainted unusable addresses.

Oh, please. NAT all over again? That’s another inherently very good reason
NOT to use ULA.

Owen

> 
> 
> On 2 March 2018 at 11:39, Enno Rey  wrote:
>> Hi,
>> 
>> On Thu, Mar 01, 2018 at 09:30:32PM -0500, Harald Koch wrote:
>>> On 1 March 2018 at 18:48, Mark Andrews  wrote:
>>> 
 ULA provide stable internal addresses which survive changing ISP
 for the average home user.
>>> 
>>> 
>>> Yeah this is pretty much what I'm doing. ULA for stable, internal addresses
>>> that I can put into the (internal) DNS: ISP prefixes for global routing.
>>> Renumbering is hard.
>> 
>> as is proper (source|destination) address selection in a sufficiently 
>> complex environment.
>> for interest: for a system which must be both globally and internally 
>> reachable, which address do you put into which DNS?
>> 
>> 
>>> 
>>> All of the objections I've seen to ULA are actually objections to (IPv6)
>>> NAT, which is why I was confused.
>> 
>> the main objection against ULAs is avoidance of complexity in environments 
>> where at least some systems need global reach(ability), which applies to 
>> pretty much all environments nowadays.
>> 
>> best
>> 
>> Enno
>> 
>> 
>> 
>> 
>> 
>> 
>>> 
>>> (As it turns out my ISP prefix has been static for years, but I'm too lazy
>>> to undo all of the work...)
>>> 
>>> --
>>> Harald
>> 
>> --
>> Enno Rey
>> 
>> ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
>> Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902
>> 
>> Handelsregister Mannheim: HRB 337135
>> Geschaeftsfuehrer: Matthias Luft, Enno Rey
>> 
>> ===
>> Blog: www.insinuator.net || Conference: www.troopers.de
>> Twitter: @Enno_Insinuator
>> ===
> 
> 
> 
> -- 
>  ++ytti

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

[Bjørn Mork]

Owen DeLong  writes:

> What can you do with ULA that GUA isn’t suitable for?

1) get
2) keep
3) move

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
number of applications where you care mostly about the local environment
and not so much about global connectivity.


Bjørn

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

[Bjørn Mork]

Owen DeLong  writes:

>> On Mar 2, 2018, at 3:17 AM, Bjørn Mork  wrote:
>> 
>> Owen DeLong  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  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.

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

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

You may also want to consider https://www.tunnelbroker.net/tos.php


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

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.

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.

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

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.

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.




Bjørn

Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks

[Bjørn Mork]

Owen DeLong  writes:

> I don’t agree that making RFC-1918 limitations a default in any daemon makes 
> any
> sense whatsoever.

+1

One of the more annoying anti-features I know of in this regard is the
dnsmasq rebind "protection".  It claims to protect web browsers on the
LAN against DNS rebind attacks.  But the implementation does not
consider which adresses are used on the LAN at all.  It simply blocks
any A record pointing to an RFC1918 address, making a few bogus
assumptions:
- IPv4 LAN addresses are selected from RFC1918
- RFC1918 addresses are never used on the WAN side of a CPE
- Noone use IPv6 on their LAN

It's hard to know how many users have been bitten by the first
one. You'd have to depend on this rebind "protection" in the first
place, and that would be stupid.

But the second assumption regularily bites end users when their ISP
provides some ISP internal service using RFC1918 addresses.  Which of course
is fine.

The anti-feature has been enabled by default in OpenWrt for a long time,
ref https://wiki.openwrt.org/doc/uci/dhcp#all_options , which means that
there is a large user base having this enabled without knowing.

> First, there are plenty of LANs out there that don’t use RFC-1918.
>
> Second, RFC-1918 doesn’t apply to IPv6 at all,

Could you try to explain that to the OpenWrt guys?  Thanks



Bjørn

Re: IPv6 Unique Local Addresses

[sthaug]

> > ULA at inside and 1:1 to operator address in the edge is what I've
> > been recommending to my enterprise customers since we started to offer
> > IPv6 commercially. Fits their existing processes and protects me from
> > creating tainted unusable addresses.
> 
> Oh, please. NAT all over again? That's another inherently very good reason
> NOT to use ULA.

You don't have to like it, but IPv6 NAT is already happening. Wishing
it would go away won't make it happen...

We're using ULA for our lab here, with the very explicit goal that the
boxes in question should *not* connect to the Internet. We're not using
IPv6 NAT, but I can certainly see the point of what Saku Ytti suggested.

Steinar Haug, Nethelp consulting, sth...@nethelp.no

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

[Owen DeLong]

> On Mar 1, 2018, at 6:30 PM, Harald Koch  wrote:
> 
> On 1 March 2018 at 18:48, Mark Andrews  wrote:
> 
>> ULA provide stable internal addresses which survive changing ISP
>> for the average home user.
> 
> 
> Yeah this is pretty much what I'm doing. ULA for stable, internal addresses
> that I can put into the (internal) DNS: ISP prefixes for global routing.
> Renumbering is hard.
> 
> All of the objections I've seen to ULA are actually objections to (IPv6)
> NAT, which is why I was confused.

I object to NAT more strongly than ULA, but IMHO, even if you aren’t going to 
route it, a block of GUA PI makes more sense than ULA for virtually any 
installation I can imagine.

Owen

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

[Owen DeLong]

> On Mar 1, 2018, at 5:30 PM, Mark Andrews  wrote:
> 
> 
>> On 2 Mar 2018, at 11:48 am, Matt Erculiani  wrote:
>> 
>> Not sure if this is the common thought, but if anyone has a network
>> which requires static IP assignments, they can probably justify a
>> request for a /48 from an RIR.  After all, ARIN's requirement for an
>> end-user IPv6 block is, at minimum: "Justify why IPv6 addresses from
>> an ISP or other LIR are unsuitable". I would think that ISP
>> portability would satisfy this requirement, but If I'm wrong, I'm
>> absolutely open to being corrected on this. But most home users have
>> no need for static IPs, so the dynamic ISP assignment is perfectly
>> fine.
> 
> ISP assigned addresses are perfectly fine for TALKING TO THE REST OF THE 
> WORLD.
> ISP assigned addresses are not perfectly fine for internal communication.

Meh.

ISP assigned addresses _CAN_ be used to talk to the rest of the world. PI 
addresses are also
perfectly fine for this where supported.

> With IPv6 you use ULA along side ISP assigned addresses.

With IPv6 you _CAN_ use ULA along PA.
or you can use PI.
or you can use PI along side PA.

IMHO, either of the latter two are better than the former.

> With IPv4 RFC 1918 address + NAT the home user has STATIC local addresses
> for devices that need them.  Go look at your home router’s web pages.  You
> will be able to assign static addresses to your internal machines via DHCP.

My home router doesn’t have web pages since I turned off J-web.
It also doesn’t run DHCP as a server. (It does run a DHCP client to talk to 
Comcast).

I do, however, have some static DHCP entries in my dhcpd.conf file on my dhcp 
server.

> Are YOU going to tell everyone that sets values there that they no longer
> can do the same thing for IPv6.  That they need to fully renumber all their
> devices just because the ISP gave them a different prefix this morning?

Nope… But there’s _NO_ reason that can’t do that equally well with a PI block
(or a free /48 from HE that they just don’t bother to really connect to a 
tunnel)
instead of ULA.

So… I stand by my point… ULA offers no… ZERO advantages over GUA.

All the defense of ULA makes strange assumptions about the nature of GUA.
I did not. Any form of GUA that suits the purpose is fine with me. If you’re
comfortable with PA, great. If you prefer PI, great. If you need something
free, get a /48 from HE, they hand them out on a simple web form. If you’re
using it locally, nothing says you _HAVE_ to actually turn on the tunnel.
OTOH, if you want, you’re certainly free to do so and it will solve certain 
address
selection oddities that happen with some systems when ULA is used and
greatly simplify your DNS life.

Owen

>> I think the tech will advance fast enough that keeping up with an IPv6
>> route table will be a non-issue. IPv6 adoption is, unfortunately, slow
>> enough that there will be no issues keeping up, even assuming a "slow"
>> hardware refresh cycle.
>> 
>> -M
>> 
>> On Thu, Mar 1, 2018 at 5:48 PM, Mark Andrews  wrote:
>>> 
 On 2 Mar 2018, at 9:28 am, Owen DeLong  wrote:
 
 
> On Mar 1, 2018, at 1:20 PM, Harald Koch  wrote:
> 
> On 1 March 2018 at 15:18, Owen DeLong  > wrote:
> Second, RFC-1918 doesn’t apply to IPv6 at all, and (fortunately) hardly 
> anyone
> uses ULA (the IPv6 analogue to RFC-1918).
> 
> Wait. What's the objection to ULA? Is it just that NAT is bad, or is 
> there something new?
 
 No particular objection, but I don’t see the point.
 
 What can you do with ULA that GUA isn’t suitable for?
 
 Owen
>>> 
>>> ULA provide stable internal addresses which survive changing ISP
>>> for the average home user. Now, I know you can do the same thing
>>> by going to a RIR and getting a prefix but the RIR’s aren’t setup
>>> to supply prefixes like that to 10 billion of us.
>>> 
>>> They are also in a specific range which makes setting filtering
>>> rules easier for everyone else.
>>> 
>>> Now I would love it if we could support 100 billion routes in the
>>> DFZ but we aren’t anywhere near being able to do that which would
>>> be a requirement for abandoning ULA.  Until them they have there
>>> place.
>>> 
>>> Mark
>>> --
>>> Mark Andrews, ISC
>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>>> 
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 

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

[Owen DeLong]

> On Mar 2, 2018, at 3:17 AM, Bjørn Mork  wrote:
> 
> Owen DeLong  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  and 
filling out a form. Remember to check the box for your /48.

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.

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.

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

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

Owen

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

[Owen DeLong]

For that matter, if we can kill IPv4, we have plenty of headroom for a LOT of 
IPv6 PI space.

Owen

> On Mar 1, 2018, at 4:48 PM, Matt Erculiani  wrote:
> 
> Not sure if this is the common thought, but if anyone has a network
> which requires static IP assignments, they can probably justify a
> request for a /48 from an RIR.  After all, ARIN's requirement for an
> end-user IPv6 block is, at minimum: "Justify why IPv6 addresses from
> an ISP or other LIR are unsuitable". I would think that ISP
> portability would satisfy this requirement, but If I'm wrong, I'm
> absolutely open to being corrected on this. But most home users have
> no need for static IPs, so the dynamic ISP assignment is perfectly
> fine.
> 
> I think the tech will advance fast enough that keeping up with an IPv6
> route table will be a non-issue. IPv6 adoption is, unfortunately, slow
> enough that there will be no issues keeping up, even assuming a "slow"
> hardware refresh cycle.
> 
> -M
> 
> On Thu, Mar 1, 2018 at 5:48 PM, Mark Andrews  wrote:
>> 
>>> On 2 Mar 2018, at 9:28 am, Owen DeLong  wrote:
>>> 
>>> 
 On Mar 1, 2018, at 1:20 PM, Harald Koch  wrote:
 
 On 1 March 2018 at 15:18, Owen DeLong > wrote:
 Second, RFC-1918 doesn’t apply to IPv6 at all, and (fortunately) hardly 
 anyone
 uses ULA (the IPv6 analogue to RFC-1918).
 
 Wait. What's the objection to ULA? Is it just that NAT is bad, or is there 
 something new?
>>> 
>>> No particular objection, but I don’t see the point.
>>> 
>>> What can you do with ULA that GUA isn’t suitable for?
>>> 
>>> Owen
>> 
>> ULA provide stable internal addresses which survive changing ISP
>> for the average home user. Now, I know you can do the same thing
>> by going to a RIR and getting a prefix but the RIR’s aren’t setup
>> to supply prefixes like that to 10 billion of us.
>> 
>> They are also in a specific range which makes setting filtering
>> rules easier for everyone else.
>> 
>> Now I would love it if we could support 100 billion routes in the
>> DFZ but we aren’t anywhere near being able to do that which would
>> be a requirement for abandoning ULA.  Until them they have there
>> place.
>> 
>> Mark
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>> 

Re: IPv6 Unique Local Addresses

[Owen DeLong]

> On Mar 2, 2018, at 3:50 AM, sth...@nethelp.no wrote:
> 
>>> ULA at inside and 1:1 to operator address in the edge is what I've
>>> been recommending to my enterprise customers since we started to offer
>>> IPv6 commercially. Fits their existing processes and protects me from
>>> creating tainted unusable addresses.
>> 
>> Oh, please. NAT all over again? That's another inherently very good reason
>> NOT to use ULA.
> 
> You don't have to like it, but IPv6 NAT is already happening. Wishing
> it would go away won't make it happen…

Truth.

Just like I can’t cure AIDS just by wishing, but I’m pretty sure that without 
people
talking about it, it wouldn’t go away either.

> We're using ULA for our lab here, with the very explicit goal that the
> boxes in question should *not* connect to the Internet. We're not using
> IPv6 NAT, but I can certainly see the point of what Saku Ytti suggested.
> 
> Steinar Haug, Nethelp consulting, sth...@nethelp.no 

We can agree to disagree. It’s not even unusual at this point.

Owen