Re: Use of unique local IPv6 addressing rfc4193

[Yang Yu]

On Thu, Sep 8, 2016 at 7:17 PM, Ca By  wrote:
> NAT is bad

https://www.youtube.com/watch?v=v26BAlfWBm8

IANA AS Numbers registry update

[Paula Wang]

Hi,

 

The IANA AS Numbers registry has been updated to reflect the allocation of the 
following block to LACNIC in September 2016:

 

265629-266652 Assigned by LACNIC 2016-09-08

 

You can find the IANA AS Numbers registry at:

 

http://www.iana.org/assignments/as-numbers/as-numbers.xml

 

The allocation was made in accordance with the Policy for Allocation of ASN 
Blocks to Regional Internet Registries:

 

https://www.icann.org/resources/pages/global-policy-asn-blocks-2010-09-21-en

 

Best Regards,

 

Paula Wang

IANA Specialist

ICANN

 



smime.p7s
Description: S/MIME cryptographic signature

Re: Use of unique local IPv6 addressing rfc4193

[Ryan, Spencer]

I agree with Karl.


We use the ULA space for our internal test labs. The /48's we have in use get 
routed around internally but have no chance of leaking to the internet.


Spencer Ryan | Senior Systems Administrator | 
sr...@arbor.net
Arbor Networks
+1.734.794.5033 (d) | +1.734.846.2053 (m)
www.arbornetworks.com



From: NANOG  on behalf of Karl Auer 

Sent: Thursday, September 8, 2016 8:49:34 PM
To: nanog@nanog.org
Subject: Re: Use of unique local IPv6 addressing rfc4193

On Thu, 2016-09-08 at 23:43 +, Pshem Kowalczyk wrote:
> both ways - if we decide to use it we'll have to either overlay it
> with public IPv6 space (and provide the NAT/proxy for where we don't
> have any public IPv6 assigned) or simply not use the fc00::/7 and
> skip the NAT/proxy aspects of it.

There is no necessary link between ULA addresses and NAT. You don't
have to NAT ULA, *ever*. If you need public addresses, go get them.
There are enough.

IMHO one should use ULA in only three situations:

- a completely isolated network
- for internal communications e.g. fabric management)
- for testing

Regards, K.

--
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B
Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4

Re: Use of unique local IPv6 addressing rfc4193

[Karl Auer]

On Thu, 2016-09-08 at 23:43 +, Pshem Kowalczyk wrote:
> both ways - if we decide to use it we'll have to either overlay it
> with public IPv6 space (and provide the NAT/proxy for where we don't
> have any public IPv6 assigned) or simply not use the fc00::/7 and
> skip the NAT/proxy aspects of it.

There is no necessary link between ULA addresses and NAT. You don't
have to NAT ULA, *ever*. If you need public addresses, go get them.
There are enough.

IMHO one should use ULA in only three situations:

- a completely isolated network
- for internal communications e.g. fabric management)
- for testing

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B
Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4

Re: Use of unique local IPv6 addressing rfc4193

[Ca By]

On Thursday, September 8, 2016, Pshem Kowalczyk  wrote:

> With NAT I have a single entry/exit point to those infrastructure subnets
> which can be easily policed.
> If I give them public IPs then they're routable and potentially can reach
> the internet via devices that don't police the traffic.
>
> My real question is does anyone bother with the fc00::/7 addressing or do


Yes.

That space is used for non-internet scenarios.

NAT is bad


CB

> you use your public space (and police that)?
>
> kind regards
> Pshem
>
>
> On Fri, 9 Sep 2016 at 10:27 Mark Andrews >
> wrote:
>
> >
> > In message  > sasavsnx31q_70q+udm1oeo...@mail.gmail.com >, Pshem
> Kowalczyk writes:
> > > Hi,
> > >
> > > We're looking at rolling out IPv6 to our internal DC infrastructure.
> > Those
> > > systems support only our internal network and in the IPv4 world they
> all
> > > live in 'private' space of 10.0.0.0/8. I was wondering if anyone uses
> > the
> > > fc00::/7 space for these sort of things or do ppl use a bit of their
> > public
> > > IPv6 allocation and manage the security for those ranges?
> > > I realise I'd have to use a proxy or NAT66 for the regular outbound
> > > connectivity (but we do it already for IPv4 anyway). The truth is that
> > even
> > > if we do use something out of our public allocation we're likely to do
> > the
> > > same thing (just to be sure that nothing spills out accidentally).
> > >
> > > So what do you do in this space?
> > >
> > > kind regards
> > > Pshem
> >
> > If you have a NAT you can't prevent things spilling out.  The ONLY
> > way to prevent things spilling out is to not connect the network
> > in any shape or form.
> >
> > All NAT does is make it harder to run your network and increases
> > the cost of software development.
> >
> > Mark
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> 
> >
>

Re: Use of unique local IPv6 addressing rfc4193

[Pshem Kowalczyk]

Hi,

That's why I asked the question - if anyone actually puts its as an
additional IP on their interfaces to keep it simple (and in-line with IPv4
policies, address allocation schemes, etc) or not. I can see the argument
both ways - if we decide to use it we'll have to either overlay it with
public IPv6 space (and provide the NAT/proxy for where we don't have any
public IPv6 assigned)  or simply not use the fc00::/7 and skip the
NAT/proxy aspects of it.
So one way it's aligned with what we do already (at the cost of the
overhead) the other it's not aligned (but with potentially less overhead).

kind regards
Pshem


On Fri, 9 Sep 2016 at 11:27 Mark Andrews  wrote:

>
> In message <
> caeazirxu7dh9o9ewdjfiemgdu7dt4v62w5+9+ctj2-rqznp...@mail.gmail.com>,
> Pshem Kowalczyk writes:
> > With NAT I have a single entry/exit point to those infrastructure subnets
> > which can be easily policed.
> > If I give them public IPs then they're routable and potentially can reach
> > the internet via devices that don't police the traffic.
>
> If you wish to believe that, believe that, but it is only wishful
> thinking.
>
> > My real question is does anyone bother with the fc00::/7 addressing
> or do > you use your public space (and police that)?
>
> ULA is normally used in parallel with public addressing if it is
> used.  IPv6 was designed to be deployed with multiple address and
> prefixes per interface.  When ULA is deployed you have ULA <-> ULA,
> non-ULA <-> non-ULA.  Non-privacy addresses for server functionality,
> privacy addresses for client functionality.
>
> Mark
>
> > kind regards
> > Pshem
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>

Re: Use of unique local IPv6 addressing rfc4193

[Mark Andrews]

In message 
, Pshem 
Kowalczyk writes:
> With NAT I have a single entry/exit point to those infrastructure subnets
> which can be easily policed.
> If I give them public IPs then they're routable and potentially can reach
> the internet via devices that don't police the traffic.

If you wish to believe that, believe that, but it is only wishful
thinking.

> My real question is does anyone bother with the fc00::/7 addressing
or do > you use your public space (and police that)?

ULA is normally used in parallel with public addressing if it is
used.  IPv6 was designed to be deployed with multiple address and
prefixes per interface.  When ULA is deployed you have ULA <-> ULA,
non-ULA <-> non-ULA.  Non-privacy addresses for server functionality,
privacy addresses for client functionality.

Mark

> kind regards
> Pshem
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Use of unique local IPv6 addressing rfc4193

[Valdis . Kletnieks]

On Thu, 08 Sep 2016 23:09:28 -, Pshem Kowalczyk said:

> If I give them public IPs then they're routable and potentially can reach
> the internet via devices that don't police the traffic.

They can potentially reach the Internet even without public IPs.

All it takes is one idiot with a laptop with a Wifi and Internet
Connection Sharing.

Or one miscreant.


pgpfD9PZvJAyb.pgp
Description: PGP signature

Re: Use of unique local IPv6 addressing rfc4193

[Josh Reynolds]

You can also easily police a subnet.

On Sep 8, 2016 6:11 PM, "Pshem Kowalczyk"  wrote:

> With NAT I have a single entry/exit point to those infrastructure subnets
> which can be easily policed.
> If I give them public IPs then they're routable and potentially can reach
> the internet via devices that don't police the traffic.
>
> My real question is does anyone bother with the fc00::/7 addressing or do
> you use your public space (and police that)?
>
> kind regards
> Pshem
>
>
> On Fri, 9 Sep 2016 at 10:27 Mark Andrews  wrote:
>
> >
> > In message  > sasavsnx31q_70q+udm1oeo...@mail.gmail.com>, Pshem Kowalczyk writes:
> > > Hi,
> > >
> > > We're looking at rolling out IPv6 to our internal DC infrastructure.
> > Those
> > > systems support only our internal network and in the IPv4 world they
> all
> > > live in 'private' space of 10.0.0.0/8. I was wondering if anyone uses
> > the
> > > fc00::/7 space for these sort of things or do ppl use a bit of their
> > public
> > > IPv6 allocation and manage the security for those ranges?
> > > I realise I'd have to use a proxy or NAT66 for the regular outbound
> > > connectivity (but we do it already for IPv4 anyway). The truth is that
> > even
> > > if we do use something out of our public allocation we're likely to do
> > the
> > > same thing (just to be sure that nothing spills out accidentally).
> > >
> > > So what do you do in this space?
> > >
> > > kind regards
> > > Pshem
> >
> > If you have a NAT you can't prevent things spilling out.  The ONLY
> > way to prevent things spilling out is to not connect the network
> > in any shape or form.
> >
> > All NAT does is make it harder to run your network and increases
> > the cost of software development.
> >
> > Mark
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> >
>

Re: Use of unique local IPv6 addressing rfc4193

[Pshem Kowalczyk]

With NAT I have a single entry/exit point to those infrastructure subnets
which can be easily policed.
If I give them public IPs then they're routable and potentially can reach
the internet via devices that don't police the traffic.

My real question is does anyone bother with the fc00::/7 addressing or do
you use your public space (and police that)?

kind regards
Pshem


On Fri, 9 Sep 2016 at 10:27 Mark Andrews  wrote:

>
> In message  sasavsnx31q_70q+udm1oeo...@mail.gmail.com>, Pshem Kowalczyk writes:
> > Hi,
> >
> > We're looking at rolling out IPv6 to our internal DC infrastructure.
> Those
> > systems support only our internal network and in the IPv4 world they all
> > live in 'private' space of 10.0.0.0/8. I was wondering if anyone uses
> the
> > fc00::/7 space for these sort of things or do ppl use a bit of their
> public
> > IPv6 allocation and manage the security for those ranges?
> > I realise I'd have to use a proxy or NAT66 for the regular outbound
> > connectivity (but we do it already for IPv4 anyway). The truth is that
> even
> > if we do use something out of our public allocation we're likely to do
> the
> > same thing (just to be sure that nothing spills out accidentally).
> >
> > So what do you do in this space?
> >
> > kind regards
> > Pshem
>
> If you have a NAT you can't prevent things spilling out.  The ONLY
> way to prevent things spilling out is to not connect the network
> in any shape or form.
>
> All NAT does is make it harder to run your network and increases
> the cost of software development.
>
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>

Re: Use of unique local IPv6 addressing rfc4193

[Mark Andrews]

In message 
, Pshem 
Kowalczyk writes:
> Hi,
> 
> We're looking at rolling out IPv6 to our internal DC infrastructure. Those
> systems support only our internal network and in the IPv4 world they all
> live in 'private' space of 10.0.0.0/8. I was wondering if anyone uses the
> fc00::/7 space for these sort of things or do ppl use a bit of their public
> IPv6 allocation and manage the security for those ranges?
> I realise I'd have to use a proxy or NAT66 for the regular outbound
> connectivity (but we do it already for IPv4 anyway). The truth is that even
> if we do use something out of our public allocation we're likely to do the
> same thing (just to be sure that nothing spills out accidentally).
> 
> So what do you do in this space?
> 
> kind regards
> Pshem

If you have a NAT you can't prevent things spilling out.  The ONLY
way to prevent things spilling out is to not connect the network
in any shape or form.

All NAT does is make it harder to run your network and increases
the cost of software development.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Use of unique local IPv6 addressing rfc4193

[Pshem Kowalczyk]

Hi,

We're looking at rolling out IPv6 to our internal DC infrastructure. Those
systems support only our internal network and in the IPv4 world they all
live in 'private' space of 10.0.0.0/8. I was wondering if anyone uses the
fc00::/7 space for these sort of things or do ppl use a bit of their public
IPv6 allocation and manage the security for those ranges?
I realise I'd have to use a proxy or NAT66 for the regular outbound
connectivity (but we do it already for IPv4 anyway). The truth is that even
if we do use something out of our public allocation we're likely to do the
same thing (just to be sure that nothing spills out accidentally).

So what do you do in this space?

kind regards
Pshem

Re: Optical transceiver question

[Mikael Abrahamsson]

On Wed, 7 Sep 2016, Frank Bulk wrote:

Is it an industry practice to market distance based on the hot optics, 
not on the worst case, which is minimum TX power?


No. If this is 1310nm optics with 0.4dB/km budget, the budget figure 
should be end-of-life figure, ie worst case according to the specs.


I don't like the "kilometer" figures, that can be marketed with very 
optimistic figures. However, if the transceiver says 0 to -5 transmit, if 
it doesn't transmit 0 to -5 then it's out of spec.


I treat the kilometer figure as "marketing", and look only at the optical 
specifications. So using your figures, if the device doesn't have 0 to -5 
out, and can receive error free at -20, then it's out of spec and it 
should be replaced free of charge.


However, if they market 1310nm with 15dB link budget at 60km reach, then 
I'd consder that false marketing.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

NANOG 68 Peering Track Call for Participation

[L Sean Kennedy]

The NANOG Program Committee is looking for interested presenters for the
NANOG 68 Peering Track (10/19/2017).  If you are interested in presenting
or can suggestion a presenter, please contact the NANOG Program Committee (
nano...@nanog.org) or myself.  Possible topic areas are listed below, but
the PC welcomes other subject related to peering and interconnection.
Please note that Peering Personals will continue to be a separate activity
at NANOG 68 to be held Monday 10/17 following the program.

- Peering Economics and Interconnection models
- Measurement and Analysis specific to peering
- Alternatives to hot-potato routing
- Operations including Peering Databases
- Transit as an alternative to peering
- 100GbE Interconnection
- Validation of routing information
- Peering-specific lightning talks (10 minutes or less)

Thanks,
 Sean
NANOG Program Committee

Amazon Contact

[Shon Elliott]

Hi everyone,

Sorry for having to ask this, but I haven't been able to chase down anyone from 
Amazon. Can someone from Amazon who might be watching the list who deals with 
the Amazon Instant Video, FireTV, Music, and other streaming media sections 
please contact me off-list regarding a serious issue? I would appreciate it 
very much.


Kind Regards,
Shon Elliott, KK6TOO
selli...@getunwired.com

Pandora Contact

[Shon Elliott]

Can someone from Pandora please contact me off-list? Thanks!

Kind Regards,
Shon Elliott, KK6TOO
selli...@getunwired.com

Google Apps Contact

[Alex Wacker]

Would appreciate if someone who manages or provides support for google apps 
could contact me off list. 

-- 
Alex Wacker

Re: Chinese root CA issues rogue/fake certificates

[Matt Palmer]

On Wed, Sep 07, 2016 at 04:15:47PM -0700, Eric Kuhnke wrote:
> Further update on all known suspicious activity from Wosign:
> 
> https://wiki.mozilla.org/CA:WoSign_Issues
> 
> Seriously, what level of malice and/or incompetence does one have to rise
> to in order to be removed from the Mozilla (and hopefully Microsoft and
> Chrome) trusted root CA store?  Is this not sufficient?

At this point, it's pretty clear that WoSign as an operational CA is going
to be no more, at least as far as Mozilla is concerned.  The number of
issues is immense, and nobody on m.d.s.p is arguing in favour of keeping the
root (except WoSign).  The other major trust stores are completely opaque as
to their process, but a root pulled from Mozilla is practically dead in the
water.

The problem is that just pulling the root is extremely damaging -- to
Mozilla, and to the ecosystem.  If a root gets pulled, all the sites that
are currently using a WoSign-issued cert "stop working".  Since plenty of
people use WoSign certs (in China, as well as their "free" issuance
offering), a lot of sites go dead all at once.  Since users cannot stand to
not have their dancing kitten gifs, they'll barge through any barrier you
put in place, whether that be clicking past warnings or switching to another
browser.  Mozilla doesn't want to lose (more) market share, and training
people to click past security warnings is a really, really dumb move.

There are a number of things that could be done to reduce the mess of a
pulled root, but many of them involve the cooperation of the CA being
pulled, and it's highly unlikely that they'd be in a cooperative mood.

The relevant discussion at the moment is around how best to cause
WoSign to no longer be trusted, *without* causing collateral damage (or at
least minimising it).  Certificate Transparency can help, maybe, but
CT isn't a live query mechanism, and shipping a giant whitelist of all valid
WoSign certs is... large.

Honest Achmed had the right idea.

- Matt

Nit-pickers' corner: Chrome uses the OS trust store; Google doesn't run its
own trust store for Chrome, although it does maintain *something* for
Android.  Chrome has a cert blacklist, and its own EV treatment criteria,
but no trust store as such.