Re: IERS ponders reverse leapsecond...

[Matthew Kaufman]

On Wed, Aug 3, 2022 at 9:22 AM Jay R. Ashworth  wrote:

>
>
> Occurs to me that "the last second of today" is approximately a million
> times
> more likely as a scheduling target than "the next to last second"; they
> should
> drop 23:59:5*8* instead.


You’re probably one of those folks who wonders why all the default Unix
daily cron jobs were at 2 AM (which breaks twice a year) and not, say, 4
AM, too.

I certainly am.

Matthew

>

Re: VPN-enabled advance fee fraud

[Matthew Kaufman]

On Mon, Mar 21, 2022 at 10:33 AM TJ Trout  wrote:

> ExpressVPN does NOT and WILL NEVER log:
> IP addresses (source or VPN)
>
> Browsing history
>
> Traffic destination or metadata
>
> DNS queries
>
> We have carefully engineered our apps and VPN servers to categorically
> eliminate sensitive information. As a result, ExpressVPN can never be
> compelled to provide customer data that does not exist.
>

...until the NSL arrives.

Matthew Kaufman

Re: "Permanent" DST

[Matthew Kaufman]

On Wed, Mar 16, 2022 at 10:31 AM Owen DeLong via NANOG 
wrote:

>
>
> You’re right… Two changes to a single file in most cases:
>
> 1.  Set the correct new timezone (e.g. MST for California).
> 2.  Turn off the Daylight Stupid Time flag.
>
>
This doesn't work at all if you want to properly display times in the past.

If you are in the new PST, then the setting is PST, and the timezone file
properly has the current state as ending in November 2023 and the new state
taking effect in November 2023 and you get proper display of time before
and after the change.

If you are in the new PST and set your timezone to MST then all times
before November 2023 are displayed incorrectly.

Matthew Kaufman

Re: Facebook post-mortems...

[Matthew Kaufman]

On Tue, Oct 5, 2021 at 5:44 AM Mark Tinka  wrote:

>
>
> On 10/5/21 14:08, Jean St-Laurent via NANOG wrote:
>
> > Maybe withdrawing those routes to their NS could have been mitigated by
> having NS in separate entities.
>
> Well, doesn't really matter if you can resolve the A//MX records,
> but you can't connect to the network that is hosting the services.


Disagree for two reasons:

1. If you have some DNS working, you can point it at a static “we are down
and we know it” page much sooner.

2. If you have convinced the entire world to install tracking pixels on
their web pages that all need your IP address, it is rude to the rest of
the world’s DNS to not be able to always provide a prompt (and cacheable)
response.

>

Re: FCC grants WISPs temporary 5.9 GHz spectrum access

[Matthew Kaufman]

The cell carriers really want the federal allocation at 3300-3500, which
has amateur as secondary, thus the other pending rulemaking that will kill
some of my amateur-licensed links (and why I’m loathe to move out of 5900
down to 3400 just to have that band go away and the equipment worthless,
plus the antenna gains are lower)

Matthew Kaufman

On Wed, Apr 1, 2020 at 7:18 PM Dave Phelps  wrote:

> Perhaps I'm being cynical, but thank [deity of choice] that the cell
> carriers want it made available for this purpose.
>
> Reference: https://docs.fcc.gov/public/attachments/DOC-363451A1.pdf
>
> "...And it would help advance even further our leadership in next
> generation wireless technologies, including 5G.” says Ajit Pai.
>
> On Wed, Apr 1, 2020 at 7:57 PM Jared Mauch  wrote:
>
>> The big announcement is the 6ghz space opening up. This will be big for
>> people doing p2p links.
>>
>> Sent from my iCar
>>
>> > On Apr 1, 2020, at 8:42 PM, Sean Donelan  wrote:
>> >
>> > 
>> > I missed this announcement last week.
>> >
>> >
>> >
>> https://www.fcc.gov/document/fcc-grants-wisps-temporary-59-ghz-spectrum-access-rural-broadband
>> >
>> > The FCC’s Wireless Telecommunications Bureau today granted temporary
>> spectrum access to 33 wireless Internet service providers serving 330
>> > counties in 29 states to help them serve rural communities facing an
>> increase in broadband needs during the COVID-19 pandemic. The Special
>> Temporary Authority (STA) granted today allows these companies to use the
>> lower 45 megahertz of spectrum in the 5.9 GHz band for 60 days.
>>
>

Re: FCC grants WISPs temporary 5.9 GHz spectrum access

[Matthew Kaufman]

There’s a rulemaking in process to open the same spectrum. One might
imagine an extension until that resolves.

This will raise the noise floor on a couple of extremely long distance
links I run on the same frequencies under amateur radio rules, including
one that traverses the length of the SF peninsula. Not looking forward to
that.

Matthew Kaufman

On Wed, Apr 1, 2020 at 7:15 PM Benson Schliesser via NANOG 
wrote:

> Indeed, this does seem like good news under the current situation. It's
> good for users, and it's nice PR for both the FCC and the WISPs. But I'm
> curious: What do these 33 operators anticipate after the STA expires in 60
> days?
>
> Obviously their plans may need to adjust depending on the pandemic
> response at that time... But thinking ahead: Do the WISPs migrate users
> before the 60 days expire, or does the STA morph into something more
> permanent? What's the strategy?
>
>  - Benson
>
> On Wed, Apr 1, 2020 at 8:56 PM Jared Mauch  wrote:
>
>> The big announcement is the 6ghz space opening up. This will be big for
>> people doing p2p links.
>>
>> Sent from my iCar
>>
>> > On Apr 1, 2020, at 8:42 PM, Sean Donelan  wrote:
>> >
>> > 
>> > I missed this announcement last week.
>> >
>> >
>> >
>> https://www.fcc.gov/document/fcc-grants-wisps-temporary-59-ghz-spectrum-access-rural-broadband
>> >
>> > The FCC’s Wireless Telecommunications Bureau today granted temporary
>> spectrum access to 33 wireless Internet service providers serving 330
>> > counties in 29 states to help them serve rural communities facing an
>> increase in broadband needs during the COVID-19 pandemic. The Special
>> Temporary Authority (STA) granted today allows these companies to use the
>> lower 45 megahertz of spectrum in the 5.9 GHz band for 60 days.
>>
>

Re: QUIC traffic throttled on AT residential

[Matthew Kaufman]

On Thu, Feb 20, 2020 at 8:10 AM Ca By  wrote:

>
>
> Not indiscriminate.
>
> As Google was informed by network operators all along since 2014, ipv4 UDP
> is a major uptime threat via DDoS to access networks.
> ...
>
> Google choose not to be sensitive to that, they were told where the
> landmines were, they choose to go on anyhow.
>
>
It isn’t like they had a choice. You can’t build a transport protocol like
QUIC on top of TCP (I know, I built one of its ancestors, which also uses
UDP underneath). And if you think getting UDP through existing networks is
hard, try using a novel IP protocol number.

Matthew Kaufman

>
>

Re: RIPE our of IPv4

[Matthew Kaufman]

I get $500, not $150, when I read the price list.

On Sun, Dec 1, 2019 at 4:06 PM Owen DeLong  wrote:

> You’re saying that there are two networks that are of sufficient
> complexity/size/whatever to require PA addressing, yet lack the resources
> for $150/year in registration fees?
>
> I suppose it’s not impossible, but I’m wondering how they afford the other
> expenses associated with maintaining such a network.
>
> Owen
>
>
> On Nov 30, 2019, at 09:00 , Matthew Kaufman  wrote:
>
> I administer two networks that use legacy IPv4 blocks (one also uses an
> allocation from the 44 net)
>
> Both could have IPv6 if it was free, but neither organization has the
> funds to waste on a paid IPv6 allocation.
>
> We should have given every legacy block matching free IPv6 space, because
> early adopters are still sometimes early adopters.
>
> But you’re right, what could have been supported on a volunteer basis is
> now a profit center. Especially for IPv6, which is once-and-done if sized
> properly.
>
> Matthew Kaufman
>
> On Tue, Nov 26, 2019 at 2:29 PM  wrote:
>
>>
>> If the commitment really was to spread IPv6 far and wide IPv6 blocks
>> would be handed out for free, one per qualified customer (e.g., if you
>> have an IPv4 allocation you get one IPv6 block free), or perhaps some
>> trivial administrative fee like $10 per year.
>>
>> But the RIRs can't live on that.
>>
>> We have put them under the management of a group of five organizations
>> which are very dependent on the income from block allocations and no
>> doubt were hoping IPv6 allocations would be a boon since there will be
>> very little if any income growth from future IPv4 block allocations.
>>
>> Worse, once acquired an IPv6 block has so many billions of addresses
>> very few if any would ever need another allocation so it would hardly
>> act as a loss leader.
>>
>> I realize many still would not deploy IPv6 for various reasons such as
>> their equipment doesn't support it or they don't have the in-house
>> expertise to support it, etc tho I can't think of much other etc, a
>> few points of resistance do come up.
>>
>> --
>> -Barry Shein
>>
>> Software Tool & Die| b...@theworld.com |
>> http://www.TheWorld.com <http://www.theworld.com/>
>> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
>> The World: Since 1989  | A Public Information Utility | *oo*
>>
>
>

Re: RIPE our of IPv4

[Matthew Kaufman]

On Sat, Nov 30, 2019 at 5:55 PM Valdis Klētnieks 
wrote:

> On Sat, 30 Nov 2019 13:47:36 -0800, Matthew Kaufman said:
>
> > User apps prefer IPv6, Netflix stops, users complain
>
> And fallback to IPv4 fails to happen, why, exactly?
>
Because of the layer at which failure happens. You get connected
successfully to a Netflix that tells you that reaching it via tunnels is
prohibited by their terms of service.

Re: RIPE our of IPv4

[Matthew Kaufman]

On Sat, Nov 30, 2019 at 4:57 PM Brandon Martin 
wrote:

> On 11/30/19 4:48 PM, Matthew Kaufman wrote:
> > See previous message about legacy IPv4 holders without budget for IPv6
> blocks
>
> How slim are your margins to have been around long enough to have a legacy
> IPv4 block but not be able to afford the ARIN fees to get a comparable/very
> usable (/48 to /52 for each IPv4) amount of IPv6?  And if you don't need a
> "comparable" amount of IPv6, presumably you aren't using all your legacy
> IPv4 and can sell off part of its presumably huge allocation to get some
> funds.
> --
>

Nonprofit that acts as an ISP with a budget of a few thousand a year,
smallest allocation to an ISP would be $500/yr in fees, a substantial
fraction of budget.

>
>

Re: RIPE our of IPv4

[Matthew Kaufman]

Sorry, thought this was the Tunnels part of the thread.

Kubernetes Container networking only supported one address per pod until
well *after* V6-only clusters were in alpha, so dual-stack want an option.

Point is, plenty of popular server-side infrastructure was designed
IPv4-first as late as 2014. This is just one example of many.

Matthew Kaufman


On Sat, Nov 30, 2019 at 1:29 PM Mark Andrews  wrote:

> And how did that stop you deploying IPv6?  It’s not like you were turning
> off IPv4.
> --
> Mark Andrews
>
> On 1 Dec 2019, at 04:03, Matthew Kaufman  wrote:
>
> 
> This is a great example (but just one of many) of how server software
> development works:
>
> IANA IPv4 runout January 2011.
>
> Kubernetes initial release June 2014. Developed by Google engineers.
>
> ARIN IPv4 runout September 2015.
>
> Support for IPv6-only Kubernetes clusters alphas in 1.9, December 2017.
>
> Full support including CoreDNS support in 1.13, December 2018.
>
> Too bad nobody had warned them about IPv4 exhaustion before they started!
>
> On Mon, Nov 25, 2019 at 8:02 AM Andy Ringsmuth  wrote:
>
>>
>>
>> > On Nov 25, 2019, at 8:56 AM, Dmitry Sherman 
>> wrote:
>> >
>> > Just received a mail that RIPE is out of IPv4:
>> >
>> > Dear colleagues,
>> >
>> > Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4
>> allocation from the last remaining addresses in our available pool. We have
>> now run out of IPv4 addresses.
>>
>> Does this mean we are finally ripe for widespread IPv6 adoption?
>>
>> (Admit it, someone had to say it!)
>>
>> 
>> Andy Ringsmuth
>> 5609 Harding Drive
>> <https://www.google.com/maps/search/5609+Harding+Drive+%0D%0ALincoln,+NE+68521?entry=gmail=g>
>> Lincoln, NE 68521
>> <https://www.google.com/maps/search/5609+Harding+Drive+%0D%0ALincoln,+NE+68521?entry=gmail=g>
>> -5831
>> (402) 304-0083
>> a...@andyring.com
>
>

Re: RIPE our of IPv4

[Matthew Kaufman]

See previous message about legacy IPv4 holders without budget for IPv6
blocks

On Sat, Nov 30, 2019 at 12:15 PM Filip Hruska  wrote:

> You can announce your own IPv6 subnets through TunnelBroker.
>
> Filip
>
>
> On 30 November 2019 8:37:33 pm GMT+01:00, Matthew Kaufman <
> matt...@matthew.at> wrote:
>>
>>
>>
>> On Sat, Nov 30, 2019 at 9:21 AM Justin Streiner 
>> wrote:
>>
>>>
>>>
>>> While a tunnel from HE works perfectly well, it would be nice to have
>>> native v6 from VZ.
>>>
>>
>> Worked perfectly well. Until Netflix blocked all known tunnel providers.
>> Then my users demanded I turn IPv6 off... so I did. Won’t come back until
>> both my up streams properly support it.
>>
>> Matthew Kaufman
>>
>>>
>>>
> --
> Sent from my mobile device. Please excuse my brevity.
>

Re: RIPE our of IPv4

[Matthew Kaufman]

User apps prefer IPv6, Netflix stops, users complain

On Sat, Nov 30, 2019 at 1:29 PM Mark Andrews  wrote:

> And how did that stop you deploying IPv6?  It’s not like you were turning
> off IPv4.
> --
> Mark Andrews
>
> On 1 Dec 2019, at 04:03, Matthew Kaufman  wrote:
>
> 
> This is a great example (but just one of many) of how server software
> development works:
>
> IANA IPv4 runout January 2011.
>
> Kubernetes initial release June 2014. Developed by Google engineers.
>
> ARIN IPv4 runout September 2015.
>
> Support for IPv6-only Kubernetes clusters alphas in 1.9, December 2017.
>
> Full support including CoreDNS support in 1.13, December 2018.
>
> Too bad nobody had warned them about IPv4 exhaustion before they started!
>
> On Mon, Nov 25, 2019 at 8:02 AM Andy Ringsmuth  wrote:
>
>>
>>
>> > On Nov 25, 2019, at 8:56 AM, Dmitry Sherman 
>> wrote:
>> >
>> > Just received a mail that RIPE is out of IPv4:
>> >
>> > Dear colleagues,
>> >
>> > Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4
>> allocation from the last remaining addresses in our available pool. We have
>> now run out of IPv4 addresses.
>>
>> Does this mean we are finally ripe for widespread IPv6 adoption?
>>
>> (Admit it, someone had to say it!)
>>
>> 
>> Andy Ringsmuth
>> 5609 Harding Drive
>> <https://www.google.com/maps/search/5609+Harding+Drive+%0D%0ALincoln,+NE+68521?entry=gmail=g>
>> Lincoln, NE 68521
>> <https://www.google.com/maps/search/5609+Harding+Drive+%0D%0ALincoln,+NE+68521?entry=gmail=g>
>> -5831
>> (402) 304-0083
>> a...@andyring.com
>
>

Re: RIPE our of IPv4

[Matthew Kaufman]

On Sat, Nov 30, 2019 at 9:21 AM Justin Streiner  wrote:

>
>
> While a tunnel from HE works perfectly well, it would be nice to have
> native v6 from VZ.
>

Worked perfectly well. Until Netflix blocked all known tunnel providers.
Then my users demanded I turn IPv6 off... so I did. Won’t come back until
both my up streams properly support it.

Matthew Kaufman

>
>

Re: RIPE our of IPv4

[Matthew Kaufman]

This is a great example (but just one of many) of how server software
development works:

IANA IPv4 runout January 2011.

Kubernetes initial release June 2014. Developed by Google engineers.

ARIN IPv4 runout September 2015.

Support for IPv6-only Kubernetes clusters alphas in 1.9, December 2017.

Full support including CoreDNS support in 1.13, December 2018.

Too bad nobody had warned them about IPv4 exhaustion before they started!

On Mon, Nov 25, 2019 at 8:02 AM Andy Ringsmuth  wrote:

>
>
> > On Nov 25, 2019, at 8:56 AM, Dmitry Sherman 
> wrote:
> >
> > Just received a mail that RIPE is out of IPv4:
> >
> > Dear colleagues,
> >
> > Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4
> allocation from the last remaining addresses in our available pool. We have
> now run out of IPv4 addresses.
>
> Does this mean we are finally ripe for widespread IPv6 adoption?
>
> (Admit it, someone had to say it!)
>
> 
> Andy Ringsmuth
> 5609 Harding Drive
> Lincoln, NE 68521-5831
> (402) 304-0083
> a...@andyring.com

Re: RIPE our of IPv4

[Matthew Kaufman]

I administer two networks that use legacy IPv4 blocks (one also uses an
allocation from the 44 net)

Both could have IPv6 if it was free, but neither organization has the funds
to waste on a paid IPv6 allocation.

We should have given every legacy block matching free IPv6 space, because
early adopters are still sometimes early adopters.

But you’re right, what could have been supported on a volunteer basis is
now a profit center. Especially for IPv6, which is once-and-done if sized
properly.

Matthew Kaufman

On Tue, Nov 26, 2019 at 2:29 PM  wrote:

>
> If the commitment really was to spread IPv6 far and wide IPv6 blocks
> would be handed out for free, one per qualified customer (e.g., if you
> have an IPv4 allocation you get one IPv6 block free), or perhaps some
> trivial administrative fee like $10 per year.
>
> But the RIRs can't live on that.
>
> We have put them under the management of a group of five organizations
> which are very dependent on the income from block allocations and no
> doubt were hoping IPv6 allocations would be a boon since there will be
> very little if any income growth from future IPv4 block allocations.
>
> Worse, once acquired an IPv6 block has so many billions of addresses
> very few if any would ever need another allocation so it would hardly
> act as a loss leader.
>
> I realize many still would not deploy IPv6 for various reasons such as
> their equipment doesn't support it or they don't have the in-house
> expertise to support it, etc tho I can't think of much other etc, a
> few points of resistance do come up.
>
> --
> -Barry Shein
>
> Software Tool & Die| b...@theworld.com |
> http://www.TheWorld.com
> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*
>

Re: IPv4 and Auctions

[Matthew Kaufman]

Are any of the rats using routable IP addresses?

On Fri, Oct 25, 2019 at 10:11 AM  wrote:

>
> There's a fairly famous animal behavior experiment where rats are
> allowed to multiply in a room-sized cage without control, food and
> water and basic sanitation are provided.
>
> When the cage becomes extremely crowded rats are observed gnawing on
> each other's tails.
>
> --
> -Barry Shein
>
> Software Tool & Die| b...@theworld.com |
> http://www.TheWorld.com
> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*
>

Re: 44/8

[Matthew Kaufman]

On Mon, Jul 22, 2019 at 1:36 PM John Curran  wrote:

> On 22 Jul 2019, at 4:17 PM, Matthew Kaufman  wrote:
>
> ...
>
>  That's why a real RIR for this space would have had a policy development
> process where *the community* could weigh in on ideas like "sell of 1/4 of
> it so we can have a big endowment". Which, heck, we might have all agreed
> to... if there was some transparency.
>
>
> Those are excellent questions for ADCR regarding its governance and
> accountability plans, but again, none of that requires any special “RIR”
> magic to accomplish; it simply takes a not-for-profit organization that
> serves its community – such entities are quite common but they require an
> active and engaged community and appropriate governance structures.
>
>
>
There's a bit of magic. If ARIN's board of directors decided to up and
start taking people's existing IPv4 allocations and selling them to Amazon
to beef up the ARIN scholarship fund, the recourse would include going to
IANA and noting that ARIN was no longer behaving as a responsible registrar
for the global community it serves.

Here the amateur radio community has noted that ARDC's board of directors
has decided to up and start taking people's existing IPv4 allocations
(including a /15 in use by the German amateur radio community) and selling
them to Amazon to beef up the ARDC grant fund (without engaging with the
global community of radio amateurs who thought that net 44 was being held
in trust for them, or engaging with even those entities/individuals who'd
already been allocated address space in the block). But because ARDC isn't
actually an IP address registrar of global IP space for its community as
delegated by IANA, we're left with grasping at ARIN for some accountability
here.

Matthew Kaufman

Re: 44/8

[Matthew Kaufman]

The change in character/purpose of the network has operational impacts to
me, and as such should have been done as an IANA action (as the original
purpose was arguably also set by IANA action, when IANA was Jon Postel, and
simply not documented very well):

I am the network administrator for a 501(c)(3) amateur radio club that
operates a digital microwave network licensed via FCC Part 101 (commercial
microwave), FCC Part 15 ("unlicensed" ISM) and FCC Part 97 (amateur radio).
The Part 97 links are, by law, restricted to amateur radio uses. One way to
ensure this is to filter based on the fact that 44.0.0.0/8 is for
international amateur radio use only. That has changed as a result of
ARIN's consent to a "transfer" to an entity that will not be using these
for the originally stated purpose. We have a /23 allocated within 44.0.0.0/8
and it is likely that as we expand we will need additional address space,
so the transfer of some of the unallocated space is of concern for that
reason as well.

What *should* have happened at the time of the formation of ARIN and the
other regional registries is that either 1) the 44.0.0.0/8 block have been
delegated to a special-purpose RIR incorporated to manage the amateur radio
allocations within this block (which is what ampr.org has been doing, but
not as an IANA-recognized community-managed RIR); or 2) the 44.0.0.0/8 block
have been delegated to another RIR (e.g., ARIN) that could have special
policies applicable only to that block and managed by the community.

I would guess that in either case, the odds that the community would have
decided to peel off 1/4 of the space and sell it to a commercial entity
would have been low, and that the odds that IANA would have agreed to go
along with such a thing at least as low.

Instead we're here, because ARIN treated "Amateur Radio Digital
Communications" not as a purpose (that happened to not be documented well
via RFC or other process) but as an organization name that anyone could
adopt, given sufficient documentation. Despite the fact that the block was
already being used in a way that you'd expect an RIR to be behaving, not
the way the organization has behaved.

Again, I'm sure that this was all well-intentioned... but nobody from ARDC
asked any of the hams like me who've been sending TCP/IP over ham radio
since it was possible, and have active allocations within the 44 net what
we thought about this idea. And nobody from ARIN asked us if we thought
ARDC was a suitable proxy for our interests in the special use of the space
either when the registration was transferred to the corporation or when the
registration stopped being used solely for its original purpose. That's why
a real RIR for this space would have had a policy development process where
*the community* could weigh in on ideas like "sell of 1/4 of it so we can
have a big endowment". Which, heck, we might have all agreed to... if there
was some transparency.

Matthew Kaufman


On Mon, Jul 22, 2019 at 12:26 PM John Curran  wrote:

> On 22 Jul 2019, at 1:16 PM, William Herrin  wrote:
> >
> > Respectfully John, this wasn't a DBA or an individual figuring the org
> name field on the old email template couldn't be blank. A class-A was
> allocated to a _purpose_.
>
> Bill -
>
> The block in question is a /8 research assignment made with a particular
> network name and a particular responsible technical contact, just as so
> many other research networks during that period; indeed, if that is what
> you meant by “purpose”, then you are correct.   Like so many of those early
> research networks, the evolution of the block over time was under control
> of the contact listed in the registry, and resulted in some being returned,
> some ending up with commercial firms, some with not-for-profit entities,
> etc.
>
> In the case of AMRPNET, in 2011 ARIN did approve update of the
> registration to a public benefit not-for-profit at the request of the
> registered contact.
>
> > You've not only allowed but encouraged that valuable resource to be
> reassigned to an organization, this ARDC, and then treated the organization
> as a proxy for the purpose. No one asked you to do that.
>
> Again, ARIN was specifically requested to do exactly that by the
> authoritative contact, and it was correct to proceed given that the IP
> block was a general purpose IP address block absent any other policy
> guidance.
>
> > Nothing in the publicly vetted policies demanded that you attach
> organizations to the purpose-based allocations
>
> You’ve suggested that this network was some special “purpose-based”
> allocation, but failed to point to any actual policy guidance that
> distinguishes it in that manner.Note that we do have many such
> documents that identify a variety of purpose-based allocations – for
> example, RFC 573

Re: Packetstream - how does this not violate just about every provider's ToS?

[Matthew Kaufman]

On Thu, Apr 25, 2019 at 1:09 PM Anne P. Mitchell, Esq. 
wrote:

>
>
> > On Apr 25, 2019, at 1:41 PM, Tom Beecher  wrote:
> >
> > It seems like just another example of liability shifting/shielding. I'll
> defer to Actual Lawyers obviously, but the way I see it, Packetstream
> doesn't have any contractual or business relationship with my ISP.  I do.
> If I sell them my bandwidth, and my ISP decides to take action, they come
> after me, not Packetstream. I can plead all I want about how I was just
> running "someone else's software" , but that isn't gonna hold up, since I
> am responsible for what is running on my home network, knowingly or
> unknowingly.
>
> And *that* is *exactly* my concern.  Because those users...('you' in this
> example)...they have *no idea* it is causing them to violate their ToS/AUP
> with their provider.
>
> And this in part, is my reason for bringing it up here in NANOG - because
> (at least some of) those big providers are here.  And those big providers
> are in the best position to stamp this out (if they think that it needs
> stamping out).


So providers should stamp this out (because it is “bad”) and support
customers who are running TOR nodes (because those are “good”). Did I get
that right?

Matthew Kaufman

>
>

Re: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space?

[Matthew Kaufman]

In other words, they’re on The Internet and you (and your transit provider)
are not.
On Thu, Dec 20, 2018 at 10:40 AM David Hubbard <
dhubb...@dino.hostasaurus.com> wrote:

> Google and HE don't have IPv6 connectivity with Cogent because Cogent's
> CEO has been in some decades long pissing match with them about free
> settlement free peering.  That's the unfortunate reality of the situation;
> nothing you can do other than have another route to HE/Google IPv6
> targets.  We have some Cogent circuits that are effectively useless for
> IPv6 as our customer base has heavy traffic to/from Google cloud services,
> so they can't be used for a backup / DR scenario; their only real value is
> an optimal route to other Cogent customers.  I'm slowly replacing our
> Cogent circuits when feasible because the reality is our customers reaching
> Google over IPv6 via all our upstreams is more valuable than Cogent's cost
> savings.
>
>
>
> On 12/20/18, 12:37 PM, "NANOG on behalf of Brian J. Murrell" <
> nanog-boun...@nanog.org on behalf of br...@interlinx.bc.ca> wrote:
>
> I've been trying to figure out why I can reach an IPv6 address at
> Facebook (2a03:2880:f012:3:face:b00c:0:1) through (only) one of my two
> Internet connections as well as via an HE IPv6 tunnel but not the other
> of my two ISP connections
>
> At one point in time a traceroute was dying inside of he.net:
>
>  Host  Loss%   Snt   Last   Avg
> Best  Wrst StDev
>  1. 2001:1970:5261:d600::1  0.0% 72.1   1.3
>  0.7   2.9   0.8
>  2. 2001:1970:4000:82::10.0% 7   10.0  14.0
>  8.3  37.9  10.6
>  3. 2001:1970:0:1a6::1 16.7% 7   13.2 215.5
> 10.8 1031. 455.9
>  4. he.ip6.torontointernetxchange.net   0.0% 7   12.3  12.9
> 11.2  15.3   1.6
>  5. 100ge9-2.core2.chi1.he.net  0.0% 7   23.6  23.0
> 21.3  27.6   2.2
>  6. 100ge15-2.core1.chi1.he.net 0.0% 7   21.7  22.5
> 21.6  24.9   1.2
>  7. 100ge12-1.core1.atl1.he.net 0.0% 7   34.2  35.1
> 34.1  36.1   0.7
>  8. 100ge5-1.core1.tpa1.he.net  0.0% 7   49.1  46.6
> 44.8  49.1   1.5
>  9. 100ge12-1.core1.mia1.he.net 0.0% 7   51.6  54.5
> 50.5  73.3   8.3
> 10. ???
>
> But I think it getting that far time was an anomaly and frankly it
> usually dies even before exiting my ISP's (Cogeco) network like this:
>
>  Host   Loss%   Snt   Last   Avg
> Best  Wrst StDev
>  1. 2001:1970:5261:d600::1   0.0%330.6   0.7
>  0.6   1.0   0.1
>  2. 2001:1970:4000:82::1 0.0%338.2  10.8
>  8.1  40.5   5.6
>  3. 2001:1970:0:1a7::1  15.2%33   23.4  20.1
> 16.5  23.4   1.5
>  4. 2001:1970:0:61::1   33.3%33   16.8  17.6
> 14.5  25.9   2.5
>  5. 2001:1978:1300::10.0%33   16.0  17.5
> 14.2  29.6   3.1
>  6. 2001:1978:203::450.0%33   30.7  30.7
> 28.4  35.1   1.7
>  7. ???
>
> When I asked the kind folks at he.net for some advice about the
> problem
> (i.e. in the first traceroute above) their diagnosis was that
> Facebook's IPv6 router(s) likely didn't have a route back to my Cogeco
> IPv6 address.
>
> Trying to talk to my ISP (again, Cogeco) has been impossible.  One
> simply cannot reach the people who know more than how to reset your
> router and configure your e-mail.
>
> I wonder how I could go any further with this to confirm the diagnosis
> that Facebook doesn't have a route to the Cogeco network's IPv6 address
> space given that I only have access to my end of the path.
>
> Cheers,
> b.
>
>
>
>

Re: Playstation/Sony Support

[Matthew Kaufman]

Every IP of mine that's banned is banned because of a hacked Mikrotik
router. Despite keeping up with the numerous updates, it seems almost every
one I own got hit in the last week.

Matthew Kaufman

On Fri, Sep 14, 2018 at 11:13 AM Dennis Burgess via NANOG 
wrote:

> I am looking for someone that can help me with a IP that appears banned
> from the PS4 network.  If you are around, please hit me off-list J
>
>
>
> Thanx,
>
>
>
>
>
> *Dennis Burgess, Mikrotik Certified Trainer *
>
> Author of "Learn RouterOS- Second Edition”
>
> *Link Technologies, Inc* -- Mikrotik & WISP Support Services
>
> *Office*: 314-735-0270 <(314)%20735-0270>  Website:
> http://www.linktechs.net
>
> Create Wireless Coverage’s with www.towercoverage.com
>
>
>

Re: Whois vs GDPR, latest news

[Matthew Kaufman]

On Mon, May 21, 2018 at 7:03 PM Jason Hellenthal 
wrote:

> Mind pointing out where in the GDPR that it directly relates to these
> types of mail services ?
>
>
>
Like most regulations, it doesn’t call out a specific thing like email or
social networking sites or ecommerce. But it follows quite directly:

GDPR covers processing of personal data of EU subjects.

Email addresses are personal data.

Article 14 says that if you receive personal data but not directly from the
subject, you must notify the subject and provide them with a variety of
information.

There are exceptions for things like scientific studies and archival
purposes... but not because it is simply inconvenient to do so.

That this probably just isn’t going to happen for any email servers or
search engine crawlers doesn’t mean the law doesn’t say what it says.

Matthew

Re: Whois vs GDPR, latest news

[Matthew Kaufman]

On Mon, May 21, 2018 at 1:56 PM Fletcher Kittredge  wrote:

> What about my right to not have this crap on NANOG?
>


What about the likely truth that if anyone from Europe mails the list, then
every mail server operator with subscribers to the list must follow the
GDPR Article 14 notification requirements, as the few exceptions appear to
not apply (unless you’re just running an archive).

Matthew

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 <o...@delong.com> wrote:

> Space from tunnel brokers is also free.
>
> Owen
>
> On Mar 2, 2018, at 12:40 PM, Matthew Kaufman <matt...@matthew.at> 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 <m...@netfire.net> wrote:
>
>> On Fri, Mar 2, 2018 at 11:08 AM, Owen DeLong <o...@delong.com> 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

[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 <m...@netfire.net> wrote:

> On Fri, Mar 2, 2018 at 11:08 AM, Owen DeLong <o...@delong.com> 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: pay.gov and IPv6

[Matthew Kaufman]

I sent email there and to another contact I had at the time.

And I'm not going to break my users by turning IPv6 back on, so someone
else will need to work with them.

Matthew Kaufman

On Thu, Nov 17, 2016 at 9:48 AM Lee <ler...@gmail.com> wrote:

> On 11/16/16, Matthew Kaufman <matt...@matthew.at> wrote:
> > The good news is that I reported this particular site as a problem two
> and
> > three years ago, both, and it isn't any worse.
>
> did you contact Pay.gov Customer Service at:
> 800-624-1373 <(800)%20624-1373> (Toll free, Option #2)
> or send an email to
> pay.gov.c...@clev.frb.org
>
> I just called, but I can't duplicate the problem and they need to work
> with someone that is having a problem reaching the site.
>
> Regards,
> Lee
>
>
> >
> > Matthew Kaufman
> > On Wed, Nov 16, 2016 at 6:29 PM Mark Andrews <ma...@isc.org> wrote:
> >
> >>
> >> In message <cc8936b2-1396-4375-85aa-a0247fd78...@consulintel.es>, JORDI
> >> PALET M
> >> ARTINEZ writes:
> >> > I think it is not just a matter of testing behind a 1280 MTU, but
> about
> >> makin
> >> > g sure that PMTUD is not broken, so it just works in any
> circumstances.
> >> >
> >> > Regards,
> >> > Jordi
> >>
> >> If you don't do MSS fix up a 1280 link in the middle will find PMTUD
> >> issues
> >> provided the testing host has a MTU > 1280.
> >>
> >> Mark
> >>
> >> > -Mensaje original-
> >> > De: NANOG <nanog-boun...@nanog.org> en nombre de Mark Andrews <
> >> ma...@isc.org>
> >> > Responder a: <ma...@isc.org>
> >> > Fecha: jueves, 17 de noviembre de 2016, 9:26
> >> > Para: Lee <ler...@gmail.com>
> >> > CC: <nanog@nanog.org>
> >> > Asunto: Re: pay.gov and IPv6
> >> >
> >> >
> >> > In message
> >> <cad8gwsvetsmn1ssfk_adttkheog0e1zfxrld11fpkbpjghm...@mail.gmai
> >> > l.com>
> >> > , Lee writes:
> >> > > On 11/16/16, Mark Andrews <ma...@isc.org> wrote:
> >> > > >
> >> > > > In message <1479249003.3937.6.ca...@ns.five-ten-sg.com>, Carl
> >> Byingto
> >> > n
> >> > > > writes
> >> > > > :
> >> > > >> -BEGIN PGP SIGNED MESSAGE-
> >> > > >> Hash: SHA512
> >> > > >>
> >> > > >> Following up on a two year old thread, one of my clients just
> >> hit th
> >> > is
> >> > > >> problem. The failure is not that www.pay.gov is not
> reachable
> >> over i
> >> > pv6
> >> > > >> (2605:3100:fffd:100::15). They accept (TCP handshake) the
> port
> >> 443
> >> > > >> connection, but the connection then hangs waiting for the TLS
> >> handsh
> >> > ake.
> >> > > >>
> >> > > >> openssl s_client -connect www.pay.gov:443
> >> > > >>
> >> > > >> openssl s_client -servername www.pay.gov -connect
> >> 199.169.192.21:443
> >> > > >>
> >> > > >> Browsers (at least firefox) see that as a very slow site, and
> >> it doe
> >> > s
> >> > > >> not trigger their happy eyeballs fast failover to ipv4.
> >> > > >
> >> > > > Happy eyeballs is about making the connection not whether TCP
> >> > > > connections work after the initial packet exchange.
> >> > > >
> >> > > > I would send a physical letter to the relevent Inspector
> >> > General
> >> > > > requesting that they ensure all web sites under their
> >> juristiction
> >> > > > that are supposed to be reachable from the public net get
> >> > audited
> >> > > > regularly to ensure that IPv6 connections work from public IP
> >> space.
> >> > >
> >> > > That will absolutely work.
> >> > >
> >> > > NIST is still monitoring ipv6 .gov sites
> >> > >   https://usgv6-deploymon.antd.nist.gov/cgi-bin/generate-gov
> >> >
> >> > Which show green which means that the tests they are doing are not
> >> > suff

Re: pay.gov and IPv6

[Matthew Kaufman]

The good news is that I reported this particular site as a problem two and
three years ago, both, and it isn't any worse.

Matthew Kaufman
On Wed, Nov 16, 2016 at 6:29 PM Mark Andrews <ma...@isc.org> wrote:

>
> In message <cc8936b2-1396-4375-85aa-a0247fd78...@consulintel.es>, JORDI
> PALET M
> ARTINEZ writes:
> > I think it is not just a matter of testing behind a 1280 MTU, but about
> makin
> > g sure that PMTUD is not broken, so it just works in any circumstances.
> >
> > Regards,
> > Jordi
>
> If you don't do MSS fix up a 1280 link in the middle will find PMTUD issues
> provided the testing host has a MTU > 1280.
>
> Mark
>
> > -Mensaje original-
> > De: NANOG <nanog-boun...@nanog.org> en nombre de Mark Andrews <
> ma...@isc.org>
> > Responder a: <ma...@isc.org>
> > Fecha: jueves, 17 de noviembre de 2016, 9:26
> > Para: Lee <ler...@gmail.com>
> > CC: <nanog@nanog.org>
> > Asunto: Re: pay.gov and IPv6
> >
> >
> > In message
> <cad8gwsvetsmn1ssfk_adttkheog0e1zfxrld11fpkbpjghm...@mail.gmai
> > l.com>
> > , Lee writes:
> > > On 11/16/16, Mark Andrews <ma...@isc.org> wrote:
> > > >
> > > > In message <1479249003.3937.6.ca...@ns.five-ten-sg.com>, Carl
> Byingto
> > n
> > > > writes
> > > > :
> > > >> -BEGIN PGP SIGNED MESSAGE-
> > > >> Hash: SHA512
> > > >>
> > > >> Following up on a two year old thread, one of my clients just
> hit th
> > is
> > > >> problem. The failure is not that www.pay.gov is not reachable
> over i
> > pv6
> > > >> (2605:3100:fffd:100::15). They accept (TCP handshake) the port
> 443
> > > >> connection, but the connection then hangs waiting for the TLS
> handsh
> > ake.
> > > >>
> > > >> openssl s_client -connect www.pay.gov:443
> > > >>
> > > >> openssl s_client -servername www.pay.gov -connect
> 199.169.192.21:443
> > > >>
> > > >> Browsers (at least firefox) see that as a very slow site, and
> it doe
> > s
> > > >> not trigger their happy eyeballs fast failover to ipv4.
> > > >
> > > > Happy eyeballs is about making the connection not whether TCP
> > > > connections work after the initial packet exchange.
> > > >
> > > > I would send a physical letter to the relevent Inspector General
> > > > requesting that they ensure all web sites under their
> juristiction
> > > > that are supposed to be reachable from the public net get audited
> > > > regularly to ensure that IPv6 connections work from public IP
> space.
> > >
> > > That will absolutely work.
> > >
> > > NIST is still monitoring ipv6 .gov sites
> > >   https://usgv6-deploymon.antd.nist.gov/cgi-bin/generate-gov
> >
> > Which show green which means that the tests they are doing are not
> > sufficient.  They need to test from behind a 1280 mtu link.
> >
> > The DNSSEC testing is also insufficient.  9-11commission.gov shows
> > green for example but if you use DNS COOKIES (which BIND 9.10.4 and
> > BIND 9.11.0 do) then servers barf and return BADVERS and validation
> > fails.  QWEST you have been informed of this already.
> >
> > Why the hell should validating resolver have to work around the
> > crap you guys are using?  DO YOUR JOBS which is to use RFC COMPLIANT
> > servers.  You get PAID to do DNS because people think you are
> > compentent to do the job.  Evidence shows otherwise.
> >
> > https://ednscomp.isc.org/compliance/gov-full-report.html show the
> broken
> > servers for .gov.  It isn't hard to check.
> >
> > > so the IG isn't going to do anything there & pay.gov has a
> contact us p
> > age
> > >   https://pay.gov/public/home/contact
> > > that I'd bet works much better than a letter to the IG
> >
> > You have to be able to get to https://pay.gov/public/home/contact
> to use
> > it.  Most people don't have the skill set to force the use of IPv4.
> >
> > If it is production it should work.  It is the I-G's role to ensure
> this
> > happens.  Butts need to kicked.
> >
> > Mark
> >
> > > Regards,
> > > Lee
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> >
> >
> >
> >
> >
> > **
> > IPv4 is over
> > Are you ready for the new Internet ?
> > http://www.consulintel.es
> > The IPv6 Company
> >
> > This electronic message contains information which may be privileged or
> confi
> > dential. The information is intended to be for the use of the
> individual(s) n
> > amed above. If you are not the intended recipient be aware that any
> disclosur
> > e, copying, distribution or use of the contents of this information,
> includin
> > g attached files, is prohibited.
> >
> >
> >
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>

Re: pay.gov and IPv6

[Matthew Kaufman]

I fixed it (and Netflix) by turning off IPv6 for all my users... but any
chance this is a path MTU issue causing the apparent hang?

Matthew Kaufman
On Wed, Nov 16, 2016 at 12:26 PM Mark Andrews <ma...@isc.org> wrote:

>
> In message <1479249003.3937.6.ca...@ns.five-ten-sg.com>, Carl Byington
> writes
> :
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > Following up on a two year old thread, one of my clients just hit this
> > problem. The failure is not that www.pay.gov is not reachable over ipv6
> > (2605:3100:fffd:100::15). They accept (TCP handshake) the port 443
> > connection, but the connection then hangs waiting for the TLS handshake.
> >
> > openssl s_client -connect www.pay.gov:443
> >
> > openssl s_client -servername www.pay.gov -connect 199.169.192.21:443
> >
> > Browsers (at least firefox) see that as a very slow site, and it does
> > not trigger their happy eyeballs fast failover to ipv4.
>
> Happy eyeballs is about making the connection not whether TCP
> connections work after the initial packet exchange.
>
> I would send a physical letter to the relevent Inspector General
> requesting that they ensure all web sites under their juristiction
> that are supposed to be reachable from the public net get audited
> regularly to ensure that IPv6 connections work from public IP space.
>
> While you are sending the letter can you also ask why pay.gov's DNS
> servers are broken.
>
> Checking: 'pay.gov' as at 2016-11-16T20:21:28Z
>
> pay.gov @199.169.194.28 (ns1.twai.gov.): edns=ok edns1=timeout edns@512=noopt
> ednsopt=ok edns1opt=timeout do=ok ednsflags=ok docookie=ok edns@512tcp=ok
> optlist=ok
> pay.gov @2605:3100:fffc:100::7 (ns1.twai.gov.): edns=ok edns1=timeout
> edns@512=noopt ednsopt=ok edns1opt=timeout do=ok ednsflags=ok docookie=ok
> edns@512tcp=ok optlist=ok
> pay.gov @199.169.192.28 (ns2.twai.gov.): edns=ok edns1=timeout edns@512=noopt
> ednsopt=ok edns1opt=timeout do=ok ednsflags=ok docookie=ok edns@512tcp=ok
> optlist=ok
> pay.gov @2605:3100:fffd:100::7 (ns2.twai.gov.): edns=ok edns1=timeout
> edns@512=noopt ednsopt=ok edns1opt=timeout do=ok ednsflags=ok docookie=ok
> edns@512tcp=ok optlist=ok
>
> Mark
>
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v2.0.14 (GNU/Linux)
> >
> > iEYEAREKAAYFAlgrjDEACgkQL6j7milTFsG8OwCgh5yRxxZHskjL4HVhzxIEmenA
> > LQgAniRMcYf/DIcg+8ve55MxUgrUbmzC
> > =MS8j
> > -END PGP SIGNATURE-
> >
> >
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>

Re: ARIN legacy block transfer process

[Matthew Kaufman]

But only the recipient must put them under an RSA in order to have them
registered. The source need not have an RSA or LRSA for their legacy
blocks, at least as I understand it.

I'd also suggest that having a broker is useful, because the few well-known
ones that exist are well-versed in the process by now, for all types of
sources and destinations.

Matthew Kaufman

On Fri, Sep 30, 2016 at 12:08 PM William Herrin <b...@herrin.us> wrote:

> On Fri, Sep 30, 2016 at 1:34 PM, Bryan Fields <br...@bryanfields.net>
> wrote:
> > On 9/30/16 1:22 PM, William Herrin wrote:
> >> Note that you can't sell the block as an "owned asset" and have ARIN
> >> recognize the change. ARIN does not recognize ownership of IP address
> >> blocks, they only recognize registration and authorized agents.
> >
> > This would seem to be in violation of what the NSF has said about this
> space.
> > I thought ARIN was slapped hard once before about this very thing?
>
> To the best of my knowledge, that's not the case. Every relevant court
> case has ended one of two ways:
>
> 1. The addresses were revoked after the POC was (correctly) determined
> not currently represent the (defunct) registrant.
> 2. The registrant consented to place the addresses under an ARIN RSA
> without a judicial ruling. (e.g. Microsoft/Nortel)
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin  her...@dirtside.com  b...@herrin.us
> Owner, Dirtside Systems . Web: <http://www.dirtside.com/>
>

Re: Looking for recommendations for a dedicated ping responder

[Matthew Kaufman]

Personally, I'd think twice before putting a box that does unthrottled
reflection of ICMP packets to their claimed source anywhere, especially not
one with a well-known address.

Matthew Kaufman

On Sat, Sep 10, 2016 at 2:01 AM James Greig <ja...@mor-pah.net> wrote:

> On one of these lists around 6 months ago a Google network engineer
> confirmed they do rate limit icmp (aside from prioritisation).
>
>  Unless there's a real issue here this is more about educating people.
> It's amazing how many still miss interpret trace routes these days.
>
> Kind regards
>
> James Greig
>
> > On 9 Sep 2016, at 23:29, Jon Lewis <jle...@lewis.org> wrote:
> >
> >> On Fri, 9 Sep 2016, Jared Mauch wrote:
> >>
> >>
> >>> On Sep 9, 2016, at 4:08 PM, Dan White <dwh...@olp.net> wrote:
> >>>
> >>> We're being caught up in some sort of peering dispute between Level 3
> and
> >>> Google (in the Dallas area), and we've fielded several calls from
> larger
> >>> customers complaining of 40-50% packet loss (to 8.8.8.8) when there
> appears
> >>> to be no actual service impacting loss.
> >>>
> >>> We currently suggest customers use a Linux server to ping against, or
> >>> another public host.
> >>>
> >>> Ideally we'd like to use a hardware based ICMP system for customer use
> -
> >>> Accedian NIDs are good at this (exceptionally low jitter) accept they
> >>> throttle at 500 pings per second.
> >>
> >> I know that the NETNOD folks did NTP in a FPGA that can do 4x 10GE,
> >> perhaps that card and code could be used to do 40G ICMP responder?
> >
> > The trouble is, LOTS of people want to ping something "out on the
> internet" to verify their connectivity, and things like GOOG's 8.8.8.8 DNS
> servers are a popular lighthouse.  I know from first hand experience
> (dealing with customers complaining about it), that GOOG, at least at some
> of the anycast nodes for the service, polices ICMP echo requests aimed at
> > 8.8.8.8 due to the quantity of those unwanted packets.
> >
> > Having a cheap/small/powerful device that can be used as a ping target,
> and getting the masses to use it are two very different things.
> >
> > Dan, are your customers missing DNS responses, or just echo replies from
> 8.8.8.8?  If the latter, ask what they'd do if thousands of people pinged
> one of their servers constantly.
> >
> > --
> > Jon Lewis, MCP :)   |  I route
> > |  therefore you are
> > _ http://www.lewis.org/~jlewis/pgp for PGP public key_
>
>

Re[2]: Netflix VPN detection - actual engineer needed

[Matthew Kaufman]

Yes. Just like any Internet connection, anywhere.

The official place where my ISP provides my service is 14 miles from my 
house, and I use microwave between the two. Some of the things that are 
on that same port are 50 miles in the opposite direction. With a 
satellite uplink, I could make that anywhere in about 1/3rd of the 
earth. When I travel, my IPSEC VPN extends that port to anywhere in the 
world.


And?

Matthew Kaufman

-- Original Message --
From: "Spencer Ryan" <sr...@arbor.net>
To: "Blair Trosper" <blair.tros...@gmail.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Sent: 6/6/2016 8:25:40 PM
Subject: Re: Netflix VPN detection - actual engineer needed

The tunnelbroker service acts exactly like a VPN. It allows you, from 
any
arbitrary location in the world with an IPv4 address, to bring traffic 
out

via one of HE's 4 POP's, while completely masking your actual location.

Re: Netflix VPN detection - actual engineer needed

[Matthew Kaufman]

If early adopter PI IPv6 was the same price as early adopter PI v4 space, my 
wife would be totally on board with this solution.

Matthew Kaufman

(Sent from my iPhone)

> On Jun 3, 2016, at 6:27 PM, Spencer Ryan <sr...@arbor.net> wrote:
> 
> Well if you have PI space just use HE's BGP tunnel offerings.
> 
> 
> *Spencer Ryan* | Senior Systems Administrator | sr...@arbor.net
> *Arbor Networks*
> +1.734.794.5033 (d) | +1.734.846.2053 (m)
> www.arbornetworks.com
> 
> On Fri, Jun 3, 2016 at 9:24 PM, Raymond Beaudoin <
> raymond.beaud...@icarustech.com> wrote:
> 
>> As an alternative, there are multiple cloud service offerings that will
>> advertise your IPv6 allocations on your behalf direct to a server in their
>> data centers. It seems pretty tongue-in-cheek, and satisfying, to turn
>> up a *> favorite virtual router instance> *and then route through it. The Internet
>> is such an amazing place.
>> 
>> On Fri, Jun 3, 2016 at 8:15 PM, Cryptographrix <cryptograph...@gmail.com>
>> wrote:
>> 
>>> Yeah I RAWRed to them pretty hard whilst being as understanding to the CS
>>> rep that it wasn't their fault.
>>> 
>>> They thought I was weird as anything.
>>> 
>>> If there are any Verizon FiOS network engineers on the thread, a fellow
>>> Verizon employee would thank you kindly for an off-thread email regarding
>>> BGP advertisement (I'll buy the IPv6 block and the drink-of-choice, you
>>> configure my account to listen for route advertisement).
>>> 
>>> Strange that it has to come to this to get "legit" IPv6 service.
>>> 
>>> 
>>> 
>>> 
>>> On Fri, Jun 3, 2016 at 9:08 PM Raymond Beaudoin <
>>> raymond.beaud...@icarustech.com> wrote:
>>> 
>>>> I wasn't originally affected on my he.net tunnel, but this evening it
>>>> started blocking. The recommended ACLs are a functional temporary
>>>> workaround, but I've also opened a request with Netflix.
>>>> 
>>>> On Fri, Jun 3, 2016 at 7:54 PM, Mark T. Ganzer <gan...@spawar.navy.mil>
>>>> wrote:
>>>> 
>>>>> So far I am not seeing a Netflix block on my he.net tunnel yet. I
>>>> connect
>>>>> to the Los Angeles node, so maybe not all of HE's address space is
>> being
>>>>> blocked.
>>>>> 
>>>>> Not going to be disabling IPv6 here either. + HAD native IPv6 from
>> Time
>>>>> Warner, but they decided to in their wisdom to disable IPv6 service
>> for
>>>>> anyone that has an Arris SB6183 due to an Arris firmware bug.  And
>> they
>>>> are
>>>>> taking their sweet time pushing out the fixed firmware update that
>>>> Comcast
>>>>> and Cox seemed to be able to push to their customers last fall.
>>>>> 
>>>>> -Mark Ganzer
>>>>> 
>>>>> 
>>>>>> On 6/3/2016 4:49 PM, Cryptographrix wrote:
>>>>>> 
>>>>>> Depends - how many US users have native IPv6 through their ISPs?
>>>>>> 
>>>>>> If I remember correctly (I can't find the source at the moment),
>> HE.net
>>>>>> represents something like 70% of IPv6 traffic in the US.
>>>>>> 
>>>>>> And yeah, not doing that - actually in the middle of an IPv6 project
>> at
>>>>>> work at the moment that's a bit important to me.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Fri, Jun 3, 2016 at 7:45 PM Baldur Norddahl <
>>>> baldur.nordd...@gmail.com
>>>>>> wrote:
>>>>>> 
>>>>>> Den 4. jun. 2016 01.26 skrev "Cryptographrix" <
>>>> cryptograph...@gmail.com>:
>>>>>>> 
>>>>>>>> The information I'm getting from Netflix support now is explicitly
>>>>>>> telling
>>>>>>> 
>>>>>>>> me to turn off IPv6 - someone might want to stop them before they
>>>>>>>> completely kill US IPv6 adoption.
>>>>>>> Not allowing he.net tunnels is not killing ipv6. You just need need
>>>>>>> native
>>>>>>> ipv6.
>>>>>>> 
>>>>>>> On the other hand it would be nice if Netflix would try the other
>>>>>>> protocol
>>>>>>> before blocking.
>> 

Re: Netflix VPN detection - actual engineer needed

[Matthew Kaufman]

Good for them. For things like Apple TV you need to turn it off at the router 
of course.

Matthew Kaufman

(Sent from my iPhone)

> On Jun 3, 2016, at 4:25 PM, Cryptographrix <cryptograph...@gmail.com> wrote:
> 
> The information I'm getting from Netflix support now is explicitly telling
> me to turn off IPv6 - someone might want to stop them before they
> completely kill US IPv6 adoption.
> 
> 
> On Fri, Jun 3, 2016 at 7:15 PM Cryptographrix <cryptograph...@gmail.com>
> wrote:
> 
>>> "What you are NOT allowed to do is impose new requirements on our
>> Internet to support your business licensing models and make it our problem"
>> 
>> They're not imposing new regulation on your internet to support their
>> business licensing models - they're imposing existing (and international)
>> regulations on someone else's business that existing distributors provide
>> controls for.
>> 
>> And that many existing online distributors provide controls for - hence
>> why they should be using the most local method of locating a person - ask
>> for permission to get the location from their device first (as is possible
>> nowadays), then try to get the location from any one of other fallback
>> methods (namely, IP geolocation).
>> 

Turning Off IPv6 for Good (was Re: Netflix VPN detection - actual engineer needed)

[Matthew Kaufman]

 Turns out it has nothing to do with my IPv4 connectivity. Neither of my 
ISPs has native IPv6 connectivity, so both require tunnels (one of them 
to HE.net, one to the ISPs own tunnel broker), and both appear to be 
detected as a non-permitted VPN. As an early IPv6 adopter, I've had IPv6 
on all my household devices for years now.


 So after having to temporarily turn off IPv6 at my desktop to fix 
issues with pay.gov (FCC license payments), and issues with various 
other things, and then remember to turn it back on again... I now have 
the reason I've been waiting for to turn it off globally for the whole 
house.


 Thanks Netflix for helping move us forward here.

Matthew Kaufman

ps. Would still be helpful if the support techs could tell from the 
error codes that the denied VPN is an IPv6 tunnel


-- Original Message --
From: "Matthew Kaufman" <matt...@matthew.at>
To: "NANOG" <nanog@nanog.org>
Sent: 6/1/2016 8:27:00 PM
Subject: Netflix VPN detection - actual engineer needed

Every device in my house is blocked from Netflix this evening due to 
their new "VPN blocker". My house is on my own IP space, and the 
outside of the NAT that the family devices are on is 198.202.199.254, 
announced by AS 11994. A simple ping from Netflix HQ in Los Gatos to my 
house should show that I'm no farther away than Santa Cruz, CA as 
microwaves fly.


Unfortunately, when one calls Netflix support to talk about this, the 
only response is to say "call your ISP and have them turn off the VPN 
software they've added to your account". And they absolutely refuse to 
escalate. Even if you tell them that you are essentially your own ISP.


So... where's the Netflix network engineer on the list who all of us 
can send these issues to directly?


Matthew Kaufman

Netflix VPN detection - actual engineer needed

[Matthew Kaufman]

Every device in my house is blocked from Netflix this evening due to 
their new "VPN blocker". My house is on my own IP space, and the outside 
of the NAT that the family devices are on is 198.202.199.254, announced 
by AS 11994. A simple ping from Netflix HQ in Los Gatos to my house 
should show that I'm no farther away than Santa Cruz, CA as microwaves 
fly.


Unfortunately, when one calls Netflix support to talk about this, the 
only response is to say "call your ISP and have them turn off the VPN 
software they've added to your account". And they absolutely refuse to 
escalate. Even if you tell them that you are essentially your own ISP.


So... where's the Netflix network engineer on the list who all of us can 
send these issues to directly?


Matthew Kaufman

Re: phone fun, was GeoIP database issues and the real world consequences

[Matthew Kaufman]

John Levine:
> 
> Bonus question: is there any way to find out whether and where a
> number's been ported without spending telco level amounts of money?
> Free would be nice.

https://www.npac.com/the-npac/access/permitted-uses-of-user-data-contact-list


Matthew Kaufman

(Sent from my iPhone)

Re: Cogent - Google - HE Fun

[Matthew Kaufman]

I come to the opposite conclusion - that this situation can persist with 
apparently no business impact to either party shows that IPv6 is still 
unnecessary.

Matthew Kaufman

(Sent from my iPhone)

> On Mar 13, 2016, at 7:31 AM, Dennis Burgess <dmburg...@linktechs.net> wrote:
> 
> In the end, google has made a choice. I think these kinds of choices will 
> delay IPv6 adoption.  
> 
> -Original Message-
> From: Damien Burke [mailto:dam...@supremebytes.com] 
> Sent: Friday, March 11, 2016 2:51 PM
> To: Mark Tinka <mark.ti...@seacom.mu>; Owen DeLong <o...@delong.com>; Dennis 
> Burgess <dmburg...@linktechs.net>
> Cc: North American Network Operators' Group <nanog@nanog.org>
> Subject: RE: Cogent - Google - HE Fun
> 
> Just received an updated statement from cogent support:
> 
> "We appreciate your concerns. This is a known issue that originates with 
> Google as it is up to their discretion as to how they announce routes to us 
> v4 or v6. 
> 
> Once again, apologies for any inconvenience."
> 
> And:
> 
> "The SLA does not cover route transit beyond our network. We cannot route to 
> IPs that are not announced to us by the IP owner, directly or through a 
> network peer."
> 

Re: About inetnum "ownership"

[Matthew Kaufman]

How come we have real property "ownership"? It is nothing but a record of 
invisible boundary lines on the surface of the earth, despite the earth and its 
land area being a shared resource for its animal and plant inhabitants.

Matthew Kaufman

(Sent from my iPhone)

> On Feb 22, 2016, at 2:03 AM, Jérôme Nicolle <jer...@ceriz.fr> wrote:
> 
> Hi,
> 
> How come we've had an inetnum market in place whereas an inetnum cannot
> have a market value ?
> 
> It's my understanding that the IP adress space is nothing but numbers
> and that RIR/LIRs are only responsible for the uniqueness of allocations
> and assignements, that is, a transfer of liability over a shared and
> common immaterial resource, between community members.
> 
> I'm wondering how did we made "Temporary and conditionnal liabality
> transfer" a synonym of "perpetual and inconditional usufruct transfer".
> 
> May you please enlight me ?
> 
> Thanks !
> 
> -- 
> Jérôme Nicolle
> +33 6 19 31 27 14

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Matthew Kaufman]

> On Jan 21, 2016, at 1:05 PM, Ca By <cb.li...@gmail.com> wrote:
> 
> On Thu, Jan 21, 2016 at 10:52 AM, Brandon Butterworth <bran...@rd.bbc.co.uk>
> wrote:
> 
>>>> On Jan 21, 2016, at 1:07 PM, Matthew D. Hardeman <
>> mharde...@ipifony.com> wrote:
>>>> Since Cogent is clearly the bad actor here (the burden being
>>>> Cogent's to prove otherwise because HE is publicly on record as saying
>>>> that theyd love to peer with Cogent)
>> 
>> I'd like to peer with all tier 1's, they are thus all bad as
>> they won't.
>> 
>> HE decided they want to be transit free for v6 and set out on
>> a campaign of providing free tunnels/transit/peering to establish
>> this. Cogent, for all their faults, are free to not accept the
>> offer.
>> 
>> Can the Cogent bashing stop now, save it for when they do something
>> properly bad.
>> 
>> brandon
> 
> Selling a service that is considered internet but does not deliver full
> internet access is generally considered properly bad.
> 
> I would not do business with either company, since neither of them provide
> a full view.
> 
> CB

I note that if IPv6 was actually important, neither one could have gotten away 
with it for so long.

Matthew Kaufman

(Sent from my iPhone)

Re: reliably detecting the presence of a bridge?

[Matthew Kaufman]

Why do you care if there's a bridge? Seems you care about higher latency, 
packet loss, lower reliability, etc. Measure what matters and act on that, 
rather than trying to guess performance from link type.

Matthew Kaufman

(Sent from my iPhone)

> On Dec 15, 2015, at 5:48 AM, Dave Taht <dave.t...@gmail.com> wrote:
> 
> I am curious if there is some sort of igmp or other form of message
> that would reliably detect if a switch had a bridge on it. How could
> deviceA detect deviceC was a bridge in this case?
> 
> deviceA  -> ethernet switch -> deviceB
>ethernet switch -> deviceC with bridged wifi and ethernet
> 
> question came up in the context of:
> 
> http://lists.alioth.debian.org/pipermail/babel-users/2015-December/002231.html
> 
> --
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> https://www.gofundme.com/savewifi

Re: All in favor or.....

[Matthew Kaufman]

If all the complaining waits until Monday morning, why fix it over the weekend?

Matthew Kaufman

(Sent from my iPhone)

> On Oct 25, 2015, at 8:35 AM, Jim Popovitch <jim...@gmail.com> wrote:
> 
> All in favor of 9x5 network operations say aye.
> 
> Geeze.
> 
> -Jim P.

Re: /27 the new /24

[Matthew Kaufman]

On 10/7/15 7:00 AM, Mark Andrews wrote:
I don't see anyone wishing it went differnetly. I see someone pointing 
out the reality that lots of ISP's are way too late to delivering 
IPv6. *Every* ISP should have been planning to deliver IPv6 by the 
time the first RIR ran out of IPv4 addresses. 


Look, I'm as much a supporter of delivering IPv6 as anyone. I've had 
IPv6 enabled on my home network (and the small data center I run in my 
garage) for over a decade now. In 2004, I made sure that IPv6 was fully 
supported in the peer-to-peer stack I developed and that eventually 
became RFC 7016. And for the last 5 years I've been pushing for IPv6 
support in the product I work on for my employer.


But the reality is that there's a whole lot of small and medium-sized 
ISPs run by fine, upstanding individuals serving their communities -- 
even in and around the San Francisco Bay Area -- that have either no or 
very limited (tunnels only) support for IPv6. That's the reality of the 
transition. And threatening these folks with the attorney general isn't 
the way to get them to adopt IPv6, nor is shaming them. They will add 
IPv6 support when it is easy to do, when their staff has the time, and 
when the economics make sense.


Meanwhile we have app developers trying to use cloud platforms that 
don't support IPv6 well (or at all), writing code while sitting in 
offices that don't have IPv6 service due either to their ISP or their 
internal IT department... and so there's another reason ISPs need to 
keep concentrating on IPv4 as their first priority.


And so, in the current actual Internet, not some hypothetical one, if 
you want your website to be seen, you get it an IPv4 address. And with 
IPv4 going for $6-$8 each and it being possible to support hundreds or 
thousands of websites on a single IPv4 address, there's really no excuse.


Will this be different in the future? I sure hope so. But we're not 
there yet.


Matthew Kaufman

Re: /27 the new /24

[Matthew Kaufman]

> On Oct 7, 2015, at 4:15 PM, Mark Andrews <ma...@isc.org> wrote:
> 
> 
> I don't have to.  I'm sure some AG will do so soon enough. 

There's always an optimist around.

Good luck with that.

Matthew Kaufman

(Sent from my iPhone)

Re: /27 the new /24

[Matthew Kaufman]

> On Oct 7, 2015, at 5:01 AM, Owen DeLong <o...@delong.com> wrote:
> 
> 
> 
> Instead, the followup question is needed… “That’s great, but how does that 
> help me reach a web site that doesn’t have and can’t get an IPv4 address?”
> 
> Owen
> 

At the present time, a web site that doesn't have and can't get an IPv4 address 
isn't "on the Internet".

That may change in the future, but right now this is the web site's fault, not 
your ISP's.

Wishing that the IPv6 transition had gone differently does not change reality.

Matthew Kaufman

(Sent from my iPhone)

Re: /27 the new /24

[Matthew Kaufman]

> On Oct 7, 2015, at 7:00 AM, Mark Andrews <ma...@isc.org> wrote:
> 
> 
> In message <a35fa880-b612-4458-bd22-323bef66a...@matthew.at>, Matthew Kaufman 
> w
> rites:
>> 
>> 
>>> On Oct 7, 2015, at 5:01 AM, Owen DeLong <o...@delong.com> wrote:
>>> =20
>>> =20
>>> =20
>>> Instead, the followup question is needed=E2=80=A6 =E2=80=9CThat=E2=80=99s g
>> =
>> reat, but how does that help me reach a web site that doesn=E2=80=99t have a=
>> nd can=E2=80=99t get an IPv4 address?=E2=80=9D
>>> =20
>>> Owen
>>> =20
>> 
>> At the present time, a web site that doesn't have and can't get an IPv4 addr=
>> ess isn't "on the Internet".
> 
> It's on the Internet.  ISP's that fail to supply IPv6 at this point
> in time are committing fraud if they claim to supply Internet
> connection.

Good luck prosecuting them for that.

Along with all the internal IT departments that are failing to deliver v6 to 
wifi and desktops.

> 
>> That may change in the future, but right now this is the web site's fault, n=
>> ot your ISP's.
> 
> No, it isn't the site's fault.  The internet ran out of IPv4 addresses
> years ago.  Not everyone can get a public adddress.  

Right. Now it is only people who can afford about $8 one time. (The going rate 
for IPv4 on the transfer market at modest block sizes)

> There are
> millions of customers without a public IPv4 address that can host
> a site because they are behind a CGN which is only needed because
> of the short sightedness of lots of ISPs failing to deliver IPv6
> to their customers.

I think you meant cannot.

Most consumer ISPs also prevent this as a matter of policy. Good luck getting 
those policies changed.

> 
>> Wishing that the IPv6 transition had gone differently does not change
>> reality.
> 
> I don't see anyone wishing it went differnetly.  I see someone
> pointing out the reality that lots of ISP's are way too late to
> delivering IPv6.

Sure, they're too late. Which is why, until there's more progress, a website 
not reachable over IPv4 is fairly useless if the goal is to serve "most of the 
users on the Internet"

> 
> *Every* ISP should have been planning to deliver IPv6 by the time
> the first RIR ran out of IPv4 addresses.  That would have been
> just-in-time engineering.  It's not like they didn't have over a
> decade to plan to do it,  It's not like there wern't reasonable
> accurate forcecasts for when that would happen.

Yeah, totally agree. Didn't happen. Still hasn't happened. Won't happen 
tomorrow.

> 
> It was not hard to see what would happen if you didn't deliver IPv6
> before the first RIR ran out.
> 
> No instead most of then stuck their heads in the sand and said "we
> have enough IPv4 addresses" without looking at whom they need to
> connect with.

Last I checked, things are still working out just fine for all of them. Despite 
the obvious concerns about the future.

Matthew Kaufman

(Sent from my iPhone)

Re: /27 the new /24

[Matthew Kaufman]

Cheaper than buying everyone TCAM

Matthew Kaufman

(Sent from my iPhone)

> On Oct 2, 2015, at 8:32 AM, Mike Hammett <na...@ics-il.net> wrote:
> 
> Much m ore than I'm willing to spend. ;-) 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> 
> 
> Midwest Internet Exchange 
> http://www.midwest-ix.com 
> 
> 
> - Original Message -
> 
> From: "Matthew Kaufman" <matt...@matthew.at> 
> To: "Justin Wilson - MTIN" <li...@mtin.net> 
> Cc: "NANOG" <nanog@nanog.org> 
> Sent: Friday, October 2, 2015 9:48:33 AM 
> Subject: Re: /27 the new /24 
> 
> A /24 isn't that expensive yet... 
> 
> Matthew Kaufman 
> 
> (Sent from my iPhone) 
> 
>> On Oct 2, 2015, at 7:32 AM, Justin Wilson - MTIN <li...@mtin.net> wrote: 
>> 
>> I was in a discussion the other day and several Tier2 providers were talking 
>> about the idea of adjusting their BGP filters to accept prefixes smaller 
>> than a /24. A few were saying they thought about going down to as small as a 
>> /27. This was mainly due to more networks coming online and not having even 
>> a /24 of IPv4 space. The first argument is against this is the potential 
>> bloat the global routing table could have. Many folks have worked hard for 
>> years to summarize and such. others were saying they would do a /26 or 
>> bigger. 
>> 
>> However, what do we do about the new networks which want to do BGP but only 
>> can get small allocations from someone (either a RIR or one of their 
>> upstreams)? 
>> 
>> Just throwing that out there. Seems like an interesting discussion. 
>> 
>> 
>> Justin Wilson 
>> j...@mtin.net 
>> 
>> --- 
>> http://www.mtin.net Owner/CEO 
>> xISP Solutions- Consulting – Data Centers - Bandwidth 
>> 
>> http://www.midwest-ix.com COO/Chairman 
>> Internet Exchange - Peering - Distributed Fabric
> 

Re: /27 the new /24

[Matthew Kaufman]

A /24 isn't that expensive yet...

Matthew Kaufman

(Sent from my iPhone)

> On Oct 2, 2015, at 7:32 AM, Justin Wilson - MTIN <li...@mtin.net> wrote:
> 
> I was in a discussion the other day and several Tier2 providers were talking 
> about the idea of adjusting their BGP filters to accept prefixes smaller than 
> a /24.  A few were saying they thought about going down to as small as a /27. 
>  This was mainly due to more networks coming online and not having even a /24 
> of IPv4 space.  The first argument is against this is the potential bloat the 
> global routing table could have.  Many folks have worked hard for years to 
> summarize and such. others were saying they would do a /26 or bigger.  
> 
> However, what do we do about the new networks which want to do BGP but only 
> can get small allocations from someone (either a RIR or one of their 
> upstreams)?
> 
> Just throwing that out there. Seems like an interesting discussion.
> 
> 
> Justin Wilson
> j...@mtin.net
> 
> ---
> http://www.mtin.net Owner/CEO
> xISP Solutions- Consulting – Data Centers - Bandwidth
> 
> http://www.midwest-ix.com  COO/Chairman
> Internet Exchange - Peering - Distributed Fabric
> 

Re: How to force rapid ipv6 adoption

[Matthew Kaufman]

On 10/1/2015 5:16 PM, Ca By wrote:


I run a large 464xlat dominated mobile network.

IPv4 bits are materially more expensive to deliver.


Isn't that simply a consequence of your engineering decision to use 
464xlat instead of native dual-stack, as was originally envisioned for 
the transition?




And, as FB has shared, IPv6 is more performant for end users, and more
performant is more profitable



Isn't that also at least partially a consequence of your engineering 
decision to use 464xlat?


Matthew Kaufman

Re: Recent trouble with QUIC?

[Matthew Kaufman]

Maybe Google should return the money you paid for access to their search engine 
and associated free applications during the time it was down.

Matthew Kaufman

(Sent from my iPhone)

> On Sep 27, 2015, at 6:38 PM, Lyle Giese <l...@lcrcomputer.net> wrote:
> 
> 
> 
>> On 09/27/15 16:16, Saku Ytti wrote:
>> On 25 September 2015 at 16:20, Ca By <cb.li...@gmail.com> wrote:
>> 
>> Hey,
>> 
>>> I remained very disappointed in how google has gone about quic.
>>> 
>>> They are dismissive of network operators concerns (quic protocol list and
>>> ietf), cause substantial outages, and have lost a lot of good will in the
>>> process
>>> 
>>> Here's your post mortem:
>>> 
>>> RFO: Google unilaterally deployed a non-standard protocol to our production
>>> environment, driving up helpdesk calls x%
>>> 
>>> After action: block udp 80/443 until production ready and standard ratified
>>> use deployed.
>> 
>> I find this attitude sad. Internet is about freedom. Google is using
>> standard IP and standard UDP over Internet, we, the network engineers
>> shouldn't care about application layer. Lot of companies run their own
>> protocols on top of TCP and UDP and there is absolutely nothing wrong
>> with that. Saying this shouldn't happen and if it does, those packets
>> should be dropped is same as saying innovation shouldn't happen.
>> Getting new IETF standard L4 protocol will take lot of time, and will
>> be much easier if we first have experience on using it, rather than
>> build standard and then hope it works without having actual data about
>> it.
>> 
>> QUIC, MinimaLT and other options for new PKI based L4 protocol are
>> very welcome. They offer compelling benefits
>> - mobility, IP address is not your identity (say hello to 'mosh' like
>> behaviour for all applications)
>> - encryption for all applications
>> - helps with buffer bloat (BW estimation and packet pacing)
>> - helps with performance/congestion (packet loss estimation and FEC
>> for redundant data, so dropped packet can be reconstructed be
>> receiver)
>> - fixes amplification (response is smaller than request)
>> - helps with DoS (proof of work) (QUIC does not have this)
>> - low latency session establishment (Especially compared to TLS/HTTP)
>> 
>> I'm sure I've omitted many others.
> 
> There are advantages to QUIC or Google would not be trying to work on it and 
> implement it.
> 
> The problem is that it has been added to a popular application(Chrome) which 
> many/most end users know little to nothing about QUIC and what the 
> implications are when a version in Chrome is defective and harmful to the 
> Internet.
> 
> Part of freedom is to minimize the harm and I think that is where the parties 
> replying to this thread diverge.  A broken change that causes harm should 
> have/could have been tested better before releasing it to the public on the 
> Internet.
> 
> Or if a bad release is let loose on the Internet, how does Google minimize 
> the harm?
> 
> Lyle Giese
> LCR Computer Services, Inc.

Re: Recent trouble with QUIC?

[Matthew Kaufman]

On 9/25/15 5:43 PM, Stephen Satchell wrote:

On 09/25/2015 04:20 PM, Ca By wrote:
RFO: Google unilaterally deployed a non-standard protocol to our 
production

environment, driving up helpdesk calls x%

After action: block udp 80/443 until production ready and standard 
ratified

use deployed.


Let me be gentle about this.  Why were you allowing 80/udp and 443/udp 
in the first place into your production environment?




Which ISP do you run that blocks UDP by default? I'm curious, so I can 
be sure I don't buy mislabeled "Internet" service from you.


Matthew Kaufman

Re: IPv6 Subscriber Access Deployments

[Matthew Kaufman]

If you can't hang 4k customers off a switch, why does IPv6 need so many bits 
for the host portion?

Matthew Kaufman

(Sent from my iPhone)

> On Sep 8, 2015, at 12:54 PM, valdis.kletni...@vt.edu wrote:
> 
> On Tue, 08 Sep 2015 19:40:44 -, Josh Moore said:
> 
>> The question becomes manageability. Unique VLAN per customer is not always
>> scalable. For example, only ~4000 VLAN tags. What happens when you have more
>> than that many customers?
> 
> If you're hanging 4K customers off the same switch, you probably have bigger
> issues than running out of VLAN tags...
> 
>> We are talking very, very, small customers here. SOHO to say the most.
>> /64 should be more than sufficient for their CPE router.
> 
> A Linksys WNDR3800 running CeroWRT (and probably OpenWRT by now) will prefer 
> to
> create multiple /64's - one for the 4 wired ports, one for private access on 
> the
> 2.4G radio, one for guest access on the 2.4, and another private/guest pair
> on the 5G radio. So there is CPE gear out there now that can blow through 5 
> /64s
> by default, and more if you enable VLANs.
> 
> A /56 allocated via DHCPv6-PD would be a *minimum*.  And prefixes are cheap,
> so you may as well hand them a /48, just in case they have a second WNDR3800
> at the other end of the building for coverage - because that one will then ask
> the upstream one for a -PD allocation.  So if you give the CPE a /48, it can
> keep a /56 for itself, and hand the downstream a /56, and they can each
> allocate /64s as needed.
> 
> And remember - prefixes are cheap and plentiful, so don't bother with /52
> or /60, just split on 8-bit boundaries to make life easier for yourself...
> 

Re: Remember Internet-In-A-Box?

[Matthew Kaufman]

On 7/15/15 7:32 PM, Mark Andrews wrote:



Go to any business with hardware that is 3-5 years old in its IT
infrastructure and devices ranging from PCs running XP to the random
consumer gear people bring in (cameras, printers, tablets, etc.) and see
how easy it is to get everything talking on an IPv6-only (no IPv4 at
all) network... including using IPv6 to do automatic updates and all the
other pieces that need to work. We're nowhere near ready for that.
None of which is the fault of the protocol.  Blame the equipement vendors
for being negligent.



I could blame the people doing IT in those environments too, but that 
doesn't make it so that nobody needs IPv4 addresses to deploy servers to 
keep talking to these folks.


Matthew Kaufman

Re: Dual stack IPv6 for IPv4 depletion

[Matthew Kaufman]

On 7/15/2015 8:25 AM, John Levine wrote:
It would be nice if it were possible to implement BCP 38 in IPv6, 
since this is the reason it isn't in IPv4.



Too bad the hazards of allowing people to use arbitrary source addresses 
weren't known when IPv6 was designed.


Matthew Kaufman

Re: Remember Internet-In-A-Box?

[Matthew Kaufman]

On 7/14/2015 11:22 PM, Mark Andrews wrote:


Yet I can take a Windows XP box.  Tell it to enable IPv6 and it
just works.  Everything that a node needed existed when Windows XP
was released.  The last 15 years has been waiting for ISP's and CPE
vendors to deliver IPv6 as a product.  This is not to say that every
vendor deployed all the parts of the protocol properly but they
existed.


This is only true for dual-stacked networks. I just tried to set up an 
IPv6-only WiFi network at my house recently, and it was a total fail due 
to non-implementation of relatively new standards... starting with the 
fact that my Juniper SRX doesn't run a load new enough to include RDNSS 
information in RAs, and some of the devices I wanted to test with 
(Android tablets) won't do DHCPv6.


The XP box is in an even worse situation if you try to run it on a 
v6-only network.


And yet we've known for years now that dual-stack wasn't going to be an 
acceptable solution, because nobody was on track to get to 100% IPv6 
before IPv4 runout happened.


Go to any business with hardware that is 3-5 years old in its IT 
infrastructure and devices ranging from PCs running XP to the random 
consumer gear people bring in (cameras, printers, tablets, etc.) and see 
how easy it is to get everything talking on an IPv6-only (no IPv4 at 
all) network... including using IPv6 to do automatic updates and all the 
other pieces that need to work. We're nowhere near ready for that.


Matthew Kaufman

Re: ARIN IPV4 Countdown

[Matthew Kaufman]

My proposal to dump the rest of the v4 space this way was rejected as a policy 
proposal already.

Matthew Kaufman

(Sent from my iPhone)

 On Jul 14, 2015, at 9:53 AM, Tony Hain alh-i...@tndh.net wrote:
 
 Owen DeLong wrote:
 I vote for a /24 lotto to get rid of the rest!
 
 That would take too long to get organized. Just suspend fees and policy
 requirements and give one to each of the first 400 requestors. Overall it
 would reduce costs related to evaluating need, so the lack of fee income
 would not be a major loss. 
 
 
 (just kidding)
 
 I am not ... It is long past time to move on, so getting rid of the
 distraction might help with those still holding out hope.
 
 Tony
 
 
 Owen
 
 On Jul 14, 2015, at 04:37 , Scott, Robert D. rob...@ufl.edu wrote:
 
 If you have been keeping an eye on the ARIN IPV4 countdown, they
 allocated their last /23 yesterday. There are only 400 /24s in the pool
 now.
 
 https://www.arin.net/resources/request/ipv4_countdown.html
 
 Robert D. Scottrob...@ufl.edu
 Network Engineer 3 352-273-0113 Phone
 UF Information Technology  321-663-0421 Cell
 Network Services   352-273-0743 FAX
 University of Florida
 Florida Lambda Rail352-294-3571 FLR NOC
 Gainesville, FL  32611 3216630...@messaging.sprintpcs.com
 

Re: Dual stack IPv6 for IPv4 depletion

[Matthew Kaufman]

On 7/9/2015 6:31 PM, John Curran wrote:
On Jul 9, 2015, at 9:02 PM, Matthew Kaufman matt...@matthew.at 
mailto:matt...@matthew.at wrote:
On Jul 9, 2015, at 4:07 PM, Owen DeLong o...@delong.com 
mailto:o...@delong.com wrote:

...
You are correct… In order for 20% of Google’s traffic to come from 
IPv6 connected devices, there would generally need to be more than 
20% of all devices connected over IPv6.


That doesn't follow at all.

One guy who has v6 and really loves youtube can account for most of it.


Matthew -

That would be the case if the measurements of “IPv6 users” were based 
on traffic or packet
counts, but Google’s measurements are based on specific pairs of HTTP 
connection attempts
(one IPv4, and one IPv6) and the ratio of those which are IPv6 
capable.  The measurement

methodology is documented in the Google research paper -
http://research.google.com/pubs/pub36240.html


Still can be accounted for with *fewer* than 20% of all devices 
connected over IPv6 (the opposite of Owen's claim). Possibly even far 
fewer, if many devices don't bother to visit Google via HTTP.


I do find it interesting that Google (and other's) graphs show much 
higher IPv6 penetration on weekends - I assume that's because 
ISP-provided CPE + default OS configs get you better chances of IPv6 
than you get using your IT department's machine image plus network 
infrastructure. Anecdotally: I have yet to work regularly at a facility 
that has IPv6 connectivity to the outside world from the WiFi networks 
that serve employee laptops. (Though for several years in the late 2000s 
I did get IPv6 addresses via RA and routing between floors (but not 
beyond)).


Matthew Kaufman

Re: Dual stack IPv6 for IPv4 depletion

[Matthew Kaufman]

On 7/9/2015 3:07 PM, Owen DeLong wrote:


Can you offer one valid reason not to give residential users /48s? Any benefit 
whatsoever?



Sure. To avoid having to go back and deal with ARIN yet again for more 
IPv6 space.


One of the hopeful outcomes of IPv6 adoption was that an ISP could get 
enough to last forever in a single transaction. But forever isn't 
very long at one /48 (or more) per customer.


Matthew Kaufman

Re: Dual stack IPv6 for IPv4 depletion

[Matthew Kaufman]

 On Jul 9, 2015, at 11:53 PM, valdis.kletni...@vt.edu wrote:
 
 On Thu, 09 Jul 2015 23:33:25 -0700, Matthew Kaufman said:
 
 One of the hopeful outcomes of IPv6 adoption was that an ISP could get
 enough to last forever in a single transaction. But forever isn't
 very long at one /48 (or more) per customer.
 
 How long does it take to blow through a /20 at /48 a customer?

A while. But the more likely case is that the guy before you asked for and got 
a /32, because that's the minimum (and already two steps up the fee scale, I 
might add)

You want ISPs to start with /20s? I'll support that over on PPML if you propose 
it. But I'll also ask for /20 to have a fee category of small.

Matthew Kaufman

(Sent from my iPhone)

Re: Dual stack IPv6 for IPv4 depletion

[Matthew Kaufman]

 On Jul 10, 2015, at 9:52 AM, Owen DeLong o...@delong.com wrote:
 
 
 On Jul 10, 2015, at 03:57 , Matthew Kaufman matt...@matthew.at wrote:
 
 
 
 On Jul 9, 2015, at 11:53 PM, valdis.kletni...@vt.edu wrote:
 
 On Thu, 09 Jul 2015 23:33:25 -0700, Matthew Kaufman said:
 
 One of the hopeful outcomes of IPv6 adoption was that an ISP could get
 enough to last forever in a single transaction. But forever isn't
 very long at one /48 (or more) per customer.
 
 How long does it take to blow through a /20 at /48 a customer?
 
 A while. But the more likely case is that the guy before you asked for and 
 got a /32, because that's the minimum (and already two steps up the fee 
 scale, I might add)
 
 You want ISPs to start with /20s? I'll support that over on PPML if you 
 propose it. But I'll also ask for /20 to have a fee category of small.
 
 Matthew Kaufman
 
 (Sent from my iPhone)
 
 According to https://www.arin.net/fees/fee_schedule.html
 
 ISP / ALLOCATIONS INITIAL REGISTRATION OR ANNUAL FEES
 Service Category  Initial Registration or Annual Fee
 (US Dollars)  IPv4 Block Size IPv6 Block Size
 XX-Small  $500/22 or smaller  /40 or smaller
 X-Small   $1,000  Larger than /22, up to and including /20Larger 
 than /40, up to and including /36
 Small $2,000  Larger than /20, up to and including /18Larger than 
 /36, up to and including /32
 Medium$4,000  Larger than /18, up to and including /16Larger 
 than /32, up to and including /28
 Large $8,000  Larger than /16, up to and including /14Larger than 
 /28, up to and including /24
 X-Large   $16,000 Larger than /14, up to and including /12Larger 
 than /24, up to and including /20
 XX-Large  $32,000 Larger than /12 Larger than /20
 
 
 If your IPv4 ISP fits in a /22 or smaller, you can hand out /48s from a /32 
 for a very long time.
   (maximum 1024 customer end-sites with no addresses reserved for your 
 own infrastructure, /32 = 65535 customer
   end sites after reserving a /48 for your infrastructure)
 If your IPv4 ISP fits in a /20 or smaller, you can hand out /48s from a /32 
 for a pretty long time.
   (maximum 4096 customer end-sites with no addresses reserved for your 
 own infrastructure, /32 = 65535 customer
   end sites after reserving a /48 for your infrastructure)
 If your IPv4 ISP fits in a /18 or smaller, you can hand out /48s from a /32 
 for quite a while.
   (maximum 16,384 customer end-sites with no addresses reserved for your 
 own infrastructure, /32 = 65535 customer
   end sites after reserving a /48 for your infrastructure).
 
 At IPv6 /18 or smaller, you’re in the same fee category as an IPv6 /32.
 
 As you go up, the situation only gets better…
 
 If your ISP uses an IPv4 /16, then you have a maximum of 65,536 customers 
 with no allowance for infrastructure.
 For free, you can get an IPv6 /28. This allows you 16,777,215 /48 end sites 
 with a /48 reserved for your infrastructure.
 
 If your ISP uses an IPv4 /14, then you have a maximum of 262,144 customers 
 with no allowance for infrastructure.
 For free, you can get an IPv6 /24 to support up to 268,435,455 /48 end sites 
 after reserving a /48 for infrastructure.
 
 Sure, Matthew is going to point out that my maximum IPv4 customer numbers 
 assume you aren’t doing CGN. That’s true.
 Let’s assume you get a ratio of 64 customers per address using CGN (the real 
 numbers are more like 8-16 customers
 per address before stuff starts to degrade badly).
 
 64 * 1024 = 65536 subscribers on a /22, assuming you have no infrastructure, 
 no servers, and no customers that
   refuse to accept densely packed CGN. At this point, you can still hand 
 out a /48 to every customer for all
   practical purposes if you have a /32 of IPv6.
 
 Yes, the ultra-tiniest of ISPs will have to pay an extra $1,500 per year for 
 their address space. Everybody else will
 actually probably be able to pay less per year for address space once they 
 can abandon IPv4, even if they give a /48
 to every single end-site.
 
 Owen
 

I use legacy IPv4 space and pay nothing. So IPv6 would be a big jump. Didn't 
even need to invoke NAT for my argument.

But I'll repeat what I said before - want ISPs handing out lots of space? Make 
the minimum /20 or /24 instead of /32. I'll support that over on the other list 
if someone proposes it.

Matthew Kaufman

(Sent from my iPhone)

Re: Dual stack IPv6 for IPv4 depletion

[Matthew Kaufman]

 On Jul 9, 2015, at 4:07 PM, Owen DeLong o...@delong.com wrote:
 
 
 On Jul 9, 2015, at 15:45 , Ricky Beam jfb...@gmail.com wrote:
 
 On Thu, 09 Jul 2015 18:05:00 -0400, Owen DeLong o...@delong.com wrote:
 Look again… IPv6 is already more than 20% of Google traffic in the US.
 
 20% of *1* site's traffic does not equal 20% DEPLOYMENT. (read: 20% of 
 internet DEVICES (CPE) connected by IPv6)
 
 You are correct… In order for 20% of Google’s traffic to come from IPv6 
 connected devices, there would generally need to be more than 20% of all 
 devices connected over IPv6.
 
 Owen
 

That doesn't follow at all.

One guy who has v6 and really loves youtube can account for most of it.

Matthew Kaufman

(Sent from my iPhone)

Re: Dual stack IPv6 for IPv4 depletion

[Matthew Kaufman]

What's excessive is 32 bits for a subnet.

No reason subnets should have been as big as they are. Bad for local forwarding 
decisions, waste of bits, etc.

Nobody has a physical subnet technology that works for more than a few thousand 
hosts anyway.

Matthew Kaufman

(Sent from my iPhone)

 On Jul 8, 2015, at 6:19 PM, Mike Hammett na...@ics-il.net wrote:
 
 /56 even seems a bit excessive for a residential user, but *shrugs* 
 
 
 
 
 - 
 Mike Hammett 
 Intelligent Computing Solutions 
 http://www.ics-il.com 
 
 
 
 Midwest Internet Exchange 
 http://www.midwest-ix.com 
 
 
 - Original Message -
 
 From: Mel Beckman m...@beckman.org 
 To: Mike Hammett na...@ics-il.net 
 Cc: NANOG nanog@nanog.org 
 Sent: Wednesday, July 8, 2015 8:11:05 PM 
 Subject: Re: Dual stack IPv6 for IPv4 depletion 
 
 Yes. The v6 allocation standards are simple, but can alarming to 
 old-schoolers who have not really thought through the math. 
 
 A customer gets a /56, which gives them 256 /64 subnets for their own 
 internal use. That accommodates all except the largest customers, and those 
 have the option of getting a /32, which gives them 4.2 billion /64s. 
 
 ISPs each get a /32 by default, which supports 16.7 million /56 customers. 
 And, of course, the /32 ISP allocation accommodates 4.2 billion ISPs. 
 
 I don't see the fear. These are just integers, after all. Nothing is really 
 going to waste. 
 
 -mel beckman 
 
 On Jul 8, 2015, at 5:58 PM, Mike Hammett na...@ics-il.net wrote: 
 
 Isn't /56 the standard end-user allocation? 
 
 
 
 
 - 
 Mike Hammett 
 Intelligent Computing Solutions 
 http://www.ics-il.com 
 
 
 
 Midwest Internet Exchange 
 http://www.midwest-ix.com 
 
 
 - Original Message - 
 
 From: Israel G. Lugo israel.l...@lugosys.com 
 To: Mark Andrews ma...@isc.org 
 Cc: NANOG nanog@nanog.org 
 Sent: Wednesday, July 8, 2015 7:45:50 PM 
 Subject: Re: Dual stack IPv6 for IPv4 depletion 
 
 
 On 07/09/2015 12:59 AM, Mark Andrews wrote: 
 In message 559db604.8060...@lugosys.com, Israel G. Lugo writes: 
 Doesn't seem to make sense at all for the ISP side, though. Standard 
 allocation /32. Giving out /48s. Even if we leave out proper subnet 
 organization and allocate fully densely, that's at most 65,536 subnets. 
 Not a very large ISP.
 /32 is not the standard allocation. It is the *minimum* allocation 
 for a ISP. ISPs are expected to ask for *more* addresses to meet their 
 actual requirements.
 
 Thank you for pointing that out. When speaking of /32 I was referring 
 specifically to RIPE policy, with which I am more familiar: Initial 
 allocation size for a LIR is /32, extensive to a /29 with minimal 
 bureaucracy. Perhaps I should have said default allocation. 
 
 I understand ISPs should ask for more addresses; however, even e.g. a 
 /24 (8x /32) seems to me like it could be roomier. 
 
 
 People usually look at IPv6 and focus on the vast numbers of individual 
 addresses. Naysayers usually get shot down with some quote mentioning 
 the number of atoms in the universe or some such. Personally, I think 
 that's a red herring; the real problem is subnets. At this rate I 
 believe subnets will become the scarce resource sooner or later.
 No. People look at /48's for sites. 35,184,372,088,832 /48 sites out of the 
 1/8th of the total IPv6 space currently in use. That is 35 trillion sites 
 and if we use that up we can look at using a different default size in the 
 next 1/8th.
 Yes, if we look at end sites individually. My hypothesis is that these 
 astronomic numbers are in fact misleading. There isn't, after all, one 
 single ISP-Of-The-World, with The-One-Big-Router. 
 
 We must divide the addresses by ISPs/LIRs, and so on. Several bits in 
 the prefix must be used for subaddressing. A larger ISP will probably 
 want to further subdivide its addressing by region, and so on. With 
 subdivisions comes waste. Which is something we don't need to worry 
 about at the LAN level, but it would be nice to have that level of 
 comfort at the subaddressing level as well. 
 
 Let's say I'm a national ISP, using 2001:db8::/32. I divide it like so: 
 
 - I reserve 1 bit for future allocation schemes, leaving me a /33; 
 - 2 bits for network type (infrastructure, residential, business, LTE): /35 
 - 3 bits for geographic region, state, whatever: /38 
 - 5 bits for PoP, or city: /43 
 
 This leaves me 5 bits for end sites: no joy. 
 
 Granted, this is just a silly example, and I don't have to divide my 
 address space like this. In fact, I really can't, unless I want to have 
 more than 32 customers per city. But I don't think it's a very 
 far-fetched example. 
 
 Perhaps I'm missing something obvious here, but it seems to me that it 
 would've been nice to have these kinds of possibilities, and more. It 
 seems counterintuitive, especially given the IPv6 way of thinking 
 which is normally encouraged: stop counting beans, this isn't IPv4. 
 
 Regards, 
 Israel G. Lugo
 

Re: Dual stack IPv6 for IPv4 depletion

[Matthew Kaufman]

On 7/4/2015 5:09 AM, Josh Moore wrote:

Traditional dual stack deployments implement both IPv4 and IPv6 to the CPE.
Consider the following:

An ISP is at 90% IPv4 utilization and would like to deploy dual stack with the 
purpose of allowing their subscriber base to continue to grow regardless of the 
depletion of the IPv4 space.


Admirable goal.


  Current dual stack best practices seem to recommend deploying BOTH IPv4 and 
IPv6 to every CPE.


That's what dual stack means, yes.


  If this is the case, and BOTH are still required, then how does IPv6 help 
with the v4 address depletion crisis?


Well, you dual-stacked your subscribers about 5-8 years ago, and about 
3-5 years ago we're basically done moving all content they might wish to 
access to IPv6 as well. So about a year ago, you've been able to offer 
an IPv6-only product that actually works just fine... and you charge 
extra for IPv4 (which most people don't want/need at this point)



  Many sites and services would still need legacy IPv4 compatibility.


Well,... because you and every other ISP dual-stacked over 5 years ago, 
and the transition is just about done, I wouldn't call it many at this 
point.



Sure, CGN technology may be a solution but what about applications that need 
direct IPv4 connectivity without NAT?


By now, there aren't any such applications in wide use. A few legacy 
things that couldn't be updated, sure, and for those you can still offer 
IPv4 addresses and access to the few people willing to pay extra for that.



It seems that there should be a mechanism to enable on-demand and efficient 
IPv4 address consumption ONLY when needed.


That's not needed, because with everyone on IPv6, there's more than 
enough IPv4 space available for you... and if you need to buy some, it 
is almost worthless, so the prices are near zero.



  My question is this: What, if any, solutions like this exist?


Nobody bothered to build sharing strategies because it was clear that it 
wouldn't be needed as IPv6 deployment ramped up over the last decade.



  If no solution exists then what is the next best thing? What would the 
overall IPv6 migration strategy and goal be?


Just continue the dual-stack approach for those who need it, as you've 
been doing for 5+ years. For the rest, IPv4 is historic.




Sorry for the length of this email but these are legitimate concerns and while 
I understand the need for IPv6 and the importance of getting there; I don't 
understand exactly HOW that can be done considering the immediate issue: IPv4 
depletion.


Fortunately, the recent ARIN announcement is of no real concern, because 
you and everyone else moved to a nearly 100% IPv6 Internet years ago.


Matthew Kaufman

Re: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6

[Matthew Kaufman]

Except for AfriNIC

And so we'll get to hear the sky is falling one last time 

Matthew Kaufman

(Sent from my iPhone)

 On Jun 27, 2015, at 2:57 AM, Randy Bush ra...@psg.com wrote:
 
 the rirs have run out of their free source of short ints to rent to us.
 i am sure everyone will move to ipv6 in a week.  news at eleven.
 
 randy

Re: Android (lack of) support for DHCPv6

[Matthew Kaufman]

On 6/8/2015 11:35 PM, Christopher Morrow wrote:

On Mon, Jun 8, 2015 at 11:19 PM, Randy Bush ra...@psg.com wrote:

We're in the beginning steps of bringing up IPv6 at the fairly large
university where I work. We plan to use DHCPv6 rather than SLAAC for a
variety of reasons. One of our guys recently noticed that Android has no
support for DHCPv6, and a rather odd issue thread discussing it:

curious about the reasoning, for what is probably singular devices on a LAN ?


Lack of RDNSS support in Windows? That's the complication on my 
IPv6-only network.


Matthew Kaufman

Re: AWS Elastic IP architecture

[Matthew Kaufman]

On 6/3/2015 4:56 AM, Owen DeLong wrote:


On Jun 2, 2015, at 4:08 PM, Matthew Kaufman matt...@matthew.at 
mailto:matt...@matthew.at wrote:



On 6/2/15 2:35 AM, Owen DeLong wrote:
On Jun 2, 2015, at 5:49 AM, Matthew Kaufman matt...@matthew.at 
mailto:matt...@matthew.at wrote:


On 6/1/2015 6:32 PM, Mark Andrews wrote:
In message 
CAL9jLaaQUP1UzoKag3Kuq8a5bMcB2q6Yg=B_=1ffwxrn6k-...@mail.gmail.com mailto:CAL9jLaaQUP1UzoKag3Kuq8a5bMcB2q6Yg=B_=1ffwxrn6k-...@mail.gmail.com

, Christopher Morrow writes:
On Mon, Jun 1, 2015 at 9:02 PM, Ca By cb.li...@gmail.com 
mailto:cb.li...@gmail.com wrote:
On Monday, June 1, 2015, Mark Andrews ma...@isc.org 
mailto:ma...@isc.org wrote:

In message
CAL9jLaYXCdfViHbUPx-=rs4vsx5mfecpfue8b7vq+au2hcx...@mail.gmail.com 
mailto:CAL9jLaYXCdfViHbUPx-=rs4vsx5mfecpfue8b7vq+au2hcx...@mail.gmail.com

, Christopher Morrow writes:

So... I don't really see any of the above arguments for v6 in a vm
setup to really hold water in the short term at least.  I 
think for
sure you'll want v6 for public services 'soon' (arguably like 
10 yrs
ago so you'd get practice and operational experience and ...) 
but for

the rest sure it's 'nice', and 'cute', but really not required for
operations (unless you have v6 only customers)

Everyone has effectively IPv6-only customers today.  IPv6 native +
CGN only works for services.  Similarly DS-Lite and 464XLAT.

ok, and for the example of 'put my service in the cloud' ... the
service is still accessible over ipv4 right?

It depends on what you are trying to do.  Having something in the
cloud manage something at home.  You can't reach the home over IPv4
more and more these days as.  IPv6 is the escape path for that but
you need both ends to be able to speak IPv6.
...and for firewalls to not exist. Since they do, absolutely all 
the techniques required to reach something at home over IPv4 are 
required for IPv6. This is on the great myths of the advantages of 
IPv6 list.
IPv4 with NAT, you can open one host at home to remote access, or, 
in some cases, you can select different hosts by using the port 
number in lieu of the host name/address.


IPv4 with NAT, standard NAT/firewall traversal techniques are used so 
that things inside your house are reachable as necessary. Almost 
nobody configures their firewall to open up anything.


HuH?

How do I SSH into my host behind my home NAT firewall without 
configuration of the firewall?


Nobody but you and a few hundred other people on this mailing list SSH 
into hosts at your home.


Everyone else in the entire world reaches hosts at their house through 
their firewall just fine because those hosts are their Nest thermostat, 
or their Dropcam, or their PC running Skype, or maybe (in rare cases) 
something like LogMeIn.


None of those people ever touch the settings of the device they had 
delivered by their ISP and/or purchased at Best Buy. Not ever.




You are making no sense here. NAT Traversal techniques provide for 
outbound connections and/or a way that a pseudo-service can create an 
inbound connection that looks like an outbound connection to the firewall.


It does not in any way provide for generic inbound access to ordinary 
services without configuration.


So what?

Nobody (to several levels of statistical significance) needs generic 
inbound access to ordinary services. Heck, the only ordinary services 
that exist any more are HTTP/HTTPS.




IPv6 — I add a permit statement to the firewall to allow the traffic 
in to each host/group of hosts that I want and I am done.


IPv6, standard NAT?firewall traversal techniques are used so that 
things inside your house are reachable as necessary. Still almost 
nobody configures their firewall to open up anything.


Why would one use NAT with IPv6… You’re making no sense there.


I didn't say you would... but you need firewall traversal, and the 
standard NAT and firewall traversal techniques are how you traverse 
your IPv6 firewall.




For those who do, the work needed to open up a few host/port mappings 
in IPv4 is basically identical to opening up a few hosts and ports 
for IPv6.


Not really…

For example, let’s say you have 20 machines for whom you want to allow 
inbound SSH access. In the IPv4 world, with NAT, you have to configure 
an individual port mapping for each machine and you have to either 
configure all of the SSH clients, or, specify the particular port for 
the machine you want to get to on the command line.


Ok, you go find me 1000 households where nobody in the house is on the 
NANOG list but where there are 20 machines running SSH already installed.





On the other hand, with IPv6, let’s say the machines are all on 
2001:db8::/64. Further, let’s say that I group machines for which I 
want to provide SSH access within 2001:db8::22:0:0:0/80. I can add a 
single firewall entry which covers this /80 and I’m done. I can put 
many millions of hosts within that range and they all are accessible 
directly for SSH from the outside world

Re: AWS Elastic IP architecture

[Matthew Kaufman]

On 6/2/15 2:35 AM, Owen DeLong wrote:

On Jun 2, 2015, at 5:49 AM, Matthew Kaufman matt...@matthew.at wrote:

On 6/1/2015 6:32 PM, Mark Andrews wrote:

In message CAL9jLaaQUP1UzoKag3Kuq8a5bMcB2q6Yg=B_=1ffwxrn6k-...@mail.gmail.com

, Christopher Morrow writes:
On Mon, Jun 1, 2015 at 9:02 PM, Ca By cb.li...@gmail.com wrote:

On Monday, June 1, 2015, Mark Andrews ma...@isc.org wrote:

In message
CAL9jLaYXCdfViHbUPx-=rs4vsx5mfecpfue8b7vq+au2hcx...@mail.gmail.com
, Christopher Morrow writes:

So... I don't really see any of the above arguments for v6 in a vm
setup to really hold water in the short term at least.  I think for
sure you'll want v6 for public services 'soon' (arguably like 10 yrs
ago so you'd get practice and operational experience and ...) but for
the rest sure it's 'nice', and 'cute', but really not required for
operations (unless you have v6 only customers)

Everyone has effectively IPv6-only customers today.  IPv6 native +
CGN only works for services.  Similarly DS-Lite and 464XLAT.

ok, and for the example of 'put my service in the cloud' ... the
service is still accessible over ipv4 right?

It depends on what you are trying to do.  Having something in the
cloud manage something at home.  You can't reach the home over IPv4
more and more these days as.  IPv6 is the escape path for that but
you need both ends to be able to speak IPv6.

...and for firewalls to not exist. Since they do, absolutely all the techniques required to 
reach something at home over IPv4 are required for IPv6. This is on the great 
myths of the advantages of IPv6 list.

IPv4 with NAT, you can open one host at home to remote access, or, in some 
cases, you can select different hosts by using the port number in lieu of the 
host name/address.


IPv4 with NAT, standard NAT/firewall traversal techniques are used so 
that things inside your house are reachable as necessary. Almost nobody 
configures their firewall to open up anything.




IPv6 — I add a permit statement to the firewall to allow the traffic in to each 
host/group of hosts that I want and I am done.


IPv6, standard NAT?firewall traversal techniques are used so that things 
inside your house are reachable as necessary. Still almost nobody 
configures their firewall to open up anything.


For those who do, the work needed to open up a few host/port mappings in 
IPv4 is basically identical to opening up a few hosts and ports for IPv6.




I do not see the above as being equal effort or as yielding equal results.


For the automatic traversal cases, the end-user effort is identical.

For the incredibly rare case of manual configuration (which as NANOG 
participants we often forget, since we're adjusting our routers all the 
time) there is almost no difference for most use cases.


Yes, the results are marginally superior in the IPv6 case. Nobody cares.



As such, I’d say that your statement gets added to the great myths of Matthew 
Kauffman rather than there being any myth about this being an IPv6 advantage.

I can assure you that it is MUCH easier for me to remote-manage my mother’s 
machines over their IPv6 addresses than to get to them over IPv4.


Only because you've insisted on doing it the hard way, instead of using 
something like teamviewer or logmein which just works.



I live in California and have native dual-stack without NAT. She lives in Texas 
and has native dual-stack with NAT for her IPv4.


And I assume your mother opened up her IPv6 firewall all on her own?

Most people won't have the technical skills to adjust the IPv6 firewall 
that comes with their CPE and/or Wireless Router any more than they 
have the skills to set up IPv4 port mapping.



IPv6 has exactly one benefit... there's more addresses. It comes with a whole 
lot of new pain points, and probably a bunch of security nightmare still 
waiting to be discovered. And it for sure isn't free.

IPv6 comes with at least one design-advantage — More addresses.

However, more addresses, especially on the scale IPv6 delivers them comes with 
MANY benefits:

1.  Simplified addressing
2.  Better aggregation
3.  Direct access where permitted
4.  Elimination of NAT and its security flaws and disadvantages
5.  Simplified topologies
6.  Better sunbathing
7.  Better network planning with sparse allocations


All of those are benefits for the network operator, not the end user.


8.  Simpler application code


Might be true *if* there was only IPv6. If there's also the need to 
support IPv4 then supporting *both* is harder than supporting just one.



9.  Reduced complexity in:
Proxies
Applications
Firewalls
Logging
Monitoring
Audit
Intrusion Detection
Intrusion Prevention
DDoS

Re: AWS Elastic IP architecture

[Matthew Kaufman]

On 6/1/15 10:12 PM, Mark Andrews wrote:

In message 556d35df.8080...@matthew.at, Matthew Kaufman writes:

On 6/1/2015 6:32 PM, Mark Andrews wrote:

In message CAL9jLaaQUP1UzoKag3Kuq8a5bMcB2q6Yg=B_=1fFWxRN6K-bNA@mail.gmail.

com

, Christopher Morrow writes:
On Mon, Jun 1, 2015 at 9:02 PM, Ca By cb.li...@gmail.com wrote:

On Monday, June 1, 2015, Mark Andrews ma...@isc.org wrote:

In message
CAL9jLaYXCdfViHbUPx-=rs4vsx5mfecpfue8b7vq+au2hcx...@mail.gmail.com
, Christopher Morrow writes:

So... I don't really see any of the above arguments for v6 in a vm
setup to really hold water in the short term at least.  I think for
sure you'll want v6 for public services 'soon' (arguably like 10 yrs
ago so you'd get practice and operational experience and ...) but for
the rest sure it's 'nice', and 'cute', but really not required for
operations (unless you have v6 only customers)

Everyone has effectively IPv6-only customers today.  IPv6 native +
CGN only works for services.  Similarly DS-Lite and 464XLAT.

ok, and for the example of 'put my service in the cloud' ... the
service is still accessible over ipv4 right?

It depends on what you are trying to do.  Having something in the
cloud manage something at home.  You can't reach the home over IPv4
more and more these days as.  IPv6 is the escape path for that but
you need both ends to be able to speak IPv6.

...and for firewalls to not exist. Since they do, absolutely all the
techniques required to reach something at home over IPv4 are required
for IPv6. This is on the great myths of the advantages of IPv6 list.

For IPv4 you port forward in the NAT possibly doing port translation
as will as address translation.


Takes about 30 seconds in the web interface of your CPE.



For IPv6 you open the port inbound in the firewall or just move the
firewalling to the host.


Takes about 30 seconds in the web interface of your CPE.



IPv6 is easier.  With modern machines you really can get rid of the
firewall in front of the machine.


For the good of the botnet operators, I encourage doing this.

I can't run my laser printer without a firewall in front of it, and I 
can't even guess how secure the controller in the septic system pump box 
might be... so I don't risk it. And I *know* that some of the webcams I 
have are vulnerable and have no updates available.



Lots of the equipement that
connects to the home nets spends plenty of time fully exposed to
the Internet w/o a firewall.


I don't believe that's accurate.


  If it does that why does it need a
firewall at home?

There is a myth that you need a firewall at home.


Perpetuated by all the actual cases of poorly designed operating systems 
and embedded systems getting attacked and making the news as a result 
(http://www.insecam.org/ among others)





IPv6 has exactly one benefit... there's more addresses. It comes with a
whole lot of new pain points, and probably a bunch of security nightmare
still waiting to be discovered. And it for sure isn't free.

It also remove a whole lot of complications.  Simplifies the security
profile.


If you think that the NDP DOS exposure is a simplification of 
security, then I'd love to hear more about the benefits of IPv6.


Matthew Kaufman

Re: AWS Elastic IP architecture

[Matthew Kaufman]

Ah, the IPv6 subnets are so big you can't find the hosts myth.

Let's see... to find which hosts are active in IPv6 I can:
- run a popular web service that people connect to, revealing their addresses
- run a DNS server that lots of folks directly use (see Google)
- use the back door login your router vendor provided and ask
- query your unsecured public SNMP and ask
- get you to install software that sends back a list of what's on your subnet
- make educated guesses about your non-privacy IP addresses based on the MAC 
address ranges of popular hardware that is available in stores this year to 
reduce the search space to a manageable size
- hack the site where you get automatic updates from and use its logs

That's just off the top of my head

Matthew Kaufman

(Sent from my iPhone)

 On Jun 2, 2015, at 9:21 AM, Nikolay Shopik sho...@inblock.ru wrote:
 
 Tell me how do you plan find printer in /64 subnet, scan it?
 
 On 02.06.2015 18:08, Matthew Kaufman wrote:
 
 I can't run my laser printer without a firewall in front of it, and I
 can't even guess how secure the controller in the septic system pump box
 might be... so I don't risk it. And I *know* that some of the webcams I
 have are vulnerable and have no updates available.

Re: AWS Elastic IP architecture

[Matthew Kaufman]

On 6/1/2015 12:06 AM, Owen DeLong wrote:
... Here’s the thing… In order to land IPv6 services without IPv6 
support on the VM, you’re creating an environment where...


Let's hypothetically say that it is much easier for the cloud provider 
if they provide just a single choice within their network, but allow 
both v4 and v6 access from the outside via a translator (to whichever 
one isn't native internally).


Would you rather have:
1) An all-IPv6 network inside, so the hosts can all talk to each other 
over IPv6 without using (potentially overlapping copies of) RFC1918 
space... but where very little of the open-source software you build 
your services on works at all, because it either doesn't support IPv6 or 
they put some IPv6 support in but it is always lagging behind and the 
bugs don't get fixed in a timely manner. Or,


2) An all-IPv4 network inside, with the annoying (but well-known) use of 
RFC1918 IPv4 space and all your software stacks just work as they always 
have, only now the fraction of users who have IPv6 can reach them over 
IPv6 if they so choose (despite the connectivity often being worse than 
the IPv4 path) and the 2 people who are on IPv6-only networks can reach 
your services too.


Until all of the common stacks that people build upon, including 
distributed databases, cache layers, web accelerators, etc. all work 
*better* when the native environment is IPv6, everyone will be choosing #2.


And both #1 and #2 are cheaper and easier to manage that full dual-stack 
to every single host (because you pay all the cost of supporting v6 
everywhere with none of the savings of not having to deal with the 
ever-increasing complexity of continuing to use v4)


Matthew Kaufman

Re: AWS Elastic IP architecture

[Matthew Kaufman]

On 6/1/2015 12:12 PM, Christopher Morrow wrote:

On Mon, Jun 1, 2015 at 1:49 PM, Matthew Kaufman matt...@matthew.at wrote:

1) An all-IPv6 network inside, so the hosts can all talk to each other over
IPv6 without using (potentially overlapping copies of) RFC1918 space...


this point keeps coming up... I don't see that 'overlapping ipv4'
matters at all here. it is presented to the customer (vm oeprator) as
'a flat-ish lan' where you poke from machine to machine via names.

(so it seems like a rathole/FUD-problem we can just stop talking about now)

-chris


I have deployed services in clouds where the overlapping RFC1918 space 
did present challenges to the software stack that was trying to exchange 
node reachability as IP/port. So yes, there were and still are cases 
where existing software that is not aware of potential overlapped 
assignments can break.


Matthew Kaufman

Re: AWS Elastic IP architecture

[Matthew Kaufman]

On 6/1/2015 6:32 PM, Mark Andrews wrote:

In message CAL9jLaaQUP1UzoKag3Kuq8a5bMcB2q6Yg=B_=1ffwxrn6k-...@mail.gmail.com

, Christopher Morrow writes:
On Mon, Jun 1, 2015 at 9:02 PM, Ca By cb.li...@gmail.com wrote:


On Monday, June 1, 2015, Mark Andrews ma...@isc.org wrote:


In message
CAL9jLaYXCdfViHbUPx-=rs4vsx5mfecpfue8b7vq+au2hcx...@mail.gmail.com
, Christopher Morrow writes:

So... I don't really see any of the above arguments for v6 in a vm
setup to really hold water in the short term at least.  I think for
sure you'll want v6 for public services 'soon' (arguably like 10 yrs
ago so you'd get practice and operational experience and ...) but for
the rest sure it's 'nice', and 'cute', but really not required for
operations (unless you have v6 only customers)

Everyone has effectively IPv6-only customers today.  IPv6 native +
CGN only works for services.  Similarly DS-Lite and 464XLAT.

ok, and for the example of 'put my service in the cloud' ... the
service is still accessible over ipv4 right?

It depends on what you are trying to do.  Having something in the
cloud manage something at home.  You can't reach the home over IPv4
more and more these days as.  IPv6 is the escape path for that but
you need both ends to be able to speak IPv6.


...and for firewalls to not exist. Since they do, absolutely all the 
techniques required to reach something at home over IPv4 are required 
for IPv6. This is on the great myths of the advantages of IPv6 list.


IPv6 has exactly one benefit... there's more addresses. It comes with a 
whole lot of new pain points, and probably a bunch of security nightmare 
still waiting to be discovered. And it for sure isn't free.


Matthew Kaufman

Re: AWS Elastic IP architecture

[Matthew Kaufman]

Since your network has IPv6, I fail to see the issue.

Nobody is anywhere near being able to go single-stack on IPv6, so AWS is just 
another network your customers will continue to reach over v4. So what?

Heck, if v6 support from a cloud hosting company is so important, I see a great 
business opportunity in your future.

Matthew Kaufman

(Sent from my iPhone)

 On May 31, 2015, at 10:57 AM, Owen DeLong o...@delong.com wrote:
 
 Sigh…
 
 IPv6 has huge utility.
 
 AWS’ implementation of IPv6 is brain-dead and mostly useless for most 
 applications.
 
 I think if you will review my track record over the last 5+ years, you will 
 plainly see that I am fully aware of the utility and need for IPv6.
 
 http://lmgtfy.com?q=owen+delong+ipv6 http://lmgtfy.com/?q=owen+delong+ipv6
 
 My network (AS1734) is fully dual-stacked, unlike AWS.
 
 If AWS is so convinced of the utility of IPv6, why do they continue to refuse 
 to do a real implementation that provides IPv6 capabilities to users of their 
 current architecture.
 
 Currently, on AWS, the only IPv6 is via ELB for classic EC2 hosts. You cannot 
 put a native IPv6 address on an AWS virtual server at all (EC2 or VPC). 
 Unless your application is satisfied by running an IPv4-only web server which 
 has an IPv6 VIP proxy in front of it with some extra headers added by the 
 proxy to help you parse out the actual source address of the connection, then 
 your application cannot use IPv6 on AWS.
 
 As such, I stand by my statement that there is effectively no meaningful 
 support for IPv6 in AWS, period.
 
 AWS may disagree and think that ELB for classic EC2 is somehow meaningful, 
 but their lack of other support for any of their modern architectures and the 
 fact that they are in the process of phasing out classic EC2 makes me think 
 that’s a pretty hard case to make.
 
 Owen
 
 On May 31, 2015, at 9:01 AM, Blair Trosper blair.tros...@gmail.com wrote:
 
 Disagree, and so does AWS.  IPv6 has a huge utility:  being a universal, 
 inter-region management network (a network that unites traffic between 
 regions on public and private netblocks).   Plus, at least the CDN and ELBs 
 should be dual-stack, since more and more ISPs are turning on IPv6.
 
 On Sun, May 31, 2015 at 8:40 AM, Owen DeLong o...@delong.com 
 mailto:o...@delong.com wrote:
 I wasn’t being specific about VPC vs. Classic.
 
 The support for IPv6 in Classic is extremely limited and basically useless 
 for 99+% of applications.
 
 I would argue that there is, therefore, effectively no meaningful support 
 for IPv6 in AWS, period.
 
 What you describe below seems to me that it would only make the situation I 
 described worse, not better in the VPC world.
 
 Owen
 
 On May 31, 2015, at 4:23 AM, Andras Toth diosbej...@gmail.com 
 mailto:diosbej...@gmail.com wrote:
 
 Congratulations for missing the point Matt, when I sent my email
 (which by the way went for moderation) there wasn't a discussion about
 Classic vs VPC yet. The discussion was no ipv6 in AWS which is not
 true as I mentioned in my previous email. I did not state it works
 everywhere, but it does work.
 
 In fact as Owen mentioned the following, I assumed he is talking about
 Classic because this statement is only true there. In VPC you can
 define your own IP subnets and it can overlap with other customers, so
 basically everyone can have their own 10.0.0.0/24 http://10.0.0.0/24 for 
 example.
 They are known to be running multiple copies of RFC-1918 in disparate
 localities already. In terms of scale, modulo the nightmare that must
 make of their management network and the fragility of what happens
 when company A in datacenter A wants to talk to company A in
 datacenter B and they both have the same 10-NET addresses
 
 Andras
 
 
 On Sun, May 31, 2015 at 7:18 PM, Matt Palmer mpal...@hezmatt.org 
 mailto:mpal...@hezmatt.org wrote:
 On Sun, May 31, 2015 at 01:38:05AM +1000, Andras Toth wrote:
 Perhaps if that energy which was spent on raging, instead was spent on
 a Google search, then all those words would've been unnecessary.
 
 Official documentation:
 http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses
  
 http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses
 
 Congratulations, you've managed to find exactly the same info as Owen
 already covered:
 
 Load balancers in a VPC support IPv4 addresses only.
 
 and
 
 Load balancers in EC2-Classic support both IPv4 and IPv6 addresses.
 
 - Matt
 

Re: AWS Elastic IP architecture

[Matthew Kaufman]

On 5/31/2015 11:57 AM, Owen DeLong wrote:
People who are building applications and considering hosting their 
applications in the cloud should seriously consider whether this 
limitation in AWS matters to them.


It doesn't, because everyone on the Internet can reach IPv4-hosted 
services.


IMHO, forward-thinking application developers will eschew AWS in favor 
of clouds that have dual-stack support and build dual-stack capable 
applications.


Forward-thinking developers are using big clouds that have the resources 
to enable IPv6 long before having IPv6 actually matters.


Matthew Kaufman

Re: link avoidance

[Matthew Kaufman]

On 5/6/2015 3:56 PM, Randy Bush wrote:

a fellow researcher wants

  to make the case that in some scenarios it is very important for a
  network operator to be able to specify that traffic should *not*
  traverse a certain switch/link/group of switches/group of links
  (that's true right?). Could you give some examples? Perhaps point
  me to relevant references?

if so, why? security?  congestion?  other?  but is it common?  and, if
so, how do you do it?

randy


I don't think it is common, but I have a microwave network made up of a 
combination of license-free links and amateur radio band links (where no 
commercial traffic is permitted). For now the ham-band links are stubs, 
so that's easy. But we're looking at using MPLS with link coloring so 
that as we do start to get redundant paths available, we can ensure that 
non-ham-radio traffic stays off the ham-band links.


Matthew Kaufman

Re: Verizon Policy Statement on Net Neutrality

[Matthew Kaufman]

+1

Th spectral split between down and up is real, has existed for a very long 
time, and isn't a master of remapping.

Matthew Kaufman

(Sent from my iPhone)

 On Feb 28, 2015, at 6:15 PM, Scott Helms khe...@zcorum.com wrote:
 
 Michael,
 
 You should really learn how DOCSIS systems work.  What you're trying to
 claim it's not only untrue it is that way for very real technical reasons.
 On Feb 28, 2015 6:27 PM, Michael Thomas m...@mtcc.com wrote:
 
 
 On 02/28/2015 03:14 PM, Clayton Zekelman wrote:
 
 You do of course realize that the asymmetry in CATV forward path/return
 path existed LONG before residential Internet access over cable networks
 exited?
 
 The cable companies didn't want servers on residential customers either,
 and were
 animated by that. Cable didn't really have much of a return path at all at
 first -- I remember
 the stories of the crappy spectrum they were willing to allocate at first,
 but as I recall
 that was mainly because they hadn't transitioned to digital downstream and
 their analog
 down was pretty precious. Once they made that transition, the animus
 against residential
 servers was pretty much the only excuse -- I'm pretty sure they could
 map up/down/cable
 channels any way they wanted after that.
 
 Mike
 
 
 Sent from my iPhone
 
 On Feb 28, 2015, at 5:38 PM, Barry Shein b...@world.std.com wrote:
 
 
 Can we stop the disingenuity?
 
 Asymmetric service was introduced to discourage home users from
 deploying commercial services. As were bandwidth caps.
 
 One can argue all sorts of other benefits of this but when this
 started that was the problem on the table: How do we forcibly
 distinguish commercial (i.e., more expensive) from non-commercial
 usage?
 
 Answer: Give them a lot less upload than download bandwidth.
 
 Originally these asymmetric, typically DSL, links were hundreds of
 kbits upstream, not a lot more than a dial-up line.
 
 That and NAT thereby making it difficult -- not impossible, the savvy
 were in the noise -- to map domain names to permanent IP addresses.
 
 That's all this was about.
 
 It's not about that's all they need, that's all they want, etc.
 
 Now that bandwidth is growing rapidly and asymmetric is often
 10/50mbps or 20/100 it almost seems nonsensical in that regard, entire
 medium-sized ISPs ran on less than 10mbps symmetric not long ago. But
 it still imposes an upper bound of sorts, along with addressing
 limitations and bandwidth caps.
 
 That's all this is about.
 
 The telcos for many decades distinguished business voice service
 from residential service, even for just one phone line, though they
 mostly just winged it and if they declared you were defrauding them by
 using a residential line for a business they might shut you off and/or
 back bill you. Residential was quite a bit cheaper, most importantly
 local unlimited (unmetered) talk was only available on residential
 lines. Business lines were even coded 1MB (one m b) service, one
 metered business (line).
 
 The history is clear and they've just reinvented the model for
 internet but proactively enforced by technology rather than studying
 your usage patterns or whatever they used to do, scan for business ads
 using residential numbers, beyond bandwidth usage analysis.
 
 And the CATV companies are trying to reinvent CATV pricing for
 internet, turn Netflix (e.g.) into an analogue of HBO and other
 premium CATV services.
 
 What's so difficult to understand here?
 
 --
-Barry Shein
 
 The World  | b...@theworld.com   |
 http://www.TheWorld.com
 Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR,
 Canada
 Software Tool  Die| Public Access Internet | SINCE 1989 *oo*
 

Re: OT - Verizon/ATT Cell/4G Signal Booster/Repeater

[Matthew Kaufman]

http://wireless.fcc.gov/signal-boosters/faq.html

Matthew Kaufman

(Sent from my iPhone)

 On Dec 15, 2014, at 6:59 PM, Ammar Zuberi am...@fastreturn.net wrote:
 
 Hi,
 
 Although this might not apply to you in the US, anyone else thinking about 
 trying this might want to check up on possible legal backlash from using one 
 of these devices. I know you can't legally use one of these in Dubai.
 
 Ammar
 
 On 16 Dec 2014, at 6:54 am, John Levine jo...@iecc.com wrote:
 
 In article 20141216024552.ga26...@esri.com you write:
 Hi all;
 
 Looking to improve cell reception for mixed ATT/Verizon users on the
 first floor of one of our buildings.
 
 Starting to dig into this and coming across items like this one at
 Amazon[1], but thought some of you out there might have recommendations
 for something that has worked well for you and has been reliable.
 
 The Wilson equipment has a good reputation.
 
 Assuming you have good Internet service, you might also consider
 femtocells, which are small cellular base stations that use your
 Internet service as backhaul.
 
 Verizon: 
 http://www.verizonwireless.com/accessories/samsung-network-extender-scs-2u01/
 
 ATT: http://www.att.com/att/microcell/
 
 R's,
 John

Re: pay.gov and IPv6

[Matthew Kaufman]

This is why I need to pull logs the next time I need to pay the FCC. There are 
several rounds of redirects involved from clicking the payment button on the 
FCC site to the final landing at pay.gov, and one of the last steps never 
connects if IPv6 is enabled.

Matthew Kaufman

(Sent from my iPhone)

 On Oct 26, 2014, at 2:16 PM, Mark Andrews ma...@isc.org wrote:
 
 
 In message 
 CAFG21ohZ6MV6Tef_sWuwV6kmAZmHQ3nFRLq-FkdU38g=vl3...@mail.gmail.com
 , Todd Lyons writes:
 On Sat, Oct 25, 2014 at 10:26 AM, Matthew Kaufman matt...@matthew.at wrote:
 
 Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov fail
 when clients have IPv6 enabled. Work fine if IPv6 is off. One more set of
 Still broken, 7 months later. And again, I was too busy trying to pay to tr
 y
 to pull a full set of logs. But if you do something on the FCC site that
 requires payment, the redirection flow dies halfway through if you're comin
 g
 from IPv6 and works fine if you turn it off... so yet another computer in
 the house has IPv6 disabled until manually turned back on.
 
 FWIW, eftps.gov is also unreachable via ipv6. I tried all of miredo,
 and my home Sixxs tunnel, and a HE tunnel from somewhere else.  I used
 the 4or6 plugin to temporarily disable ipv6 and both sites loaded
 straight away.
 
 If a site is unreachable your client should switch to IPv4 unless
 a IPv6 literal has been used.
 
 If your client take ages to switch over report a bug to the client
 vendor.
 
 It should not take ages to switch between multiple server addresses.
 IPv4 + IPv6 is just a example of multiple server addresses.
 
 eftps.gov and pay.gov appear to be managed separately since both their
 ipv4 and ipv6 netblocks are not in the same netblocks, and my path to
 them is not the same:
 
 eftps.gov has IPv6 address 2620:10f:400e:a::13
 mtr to eftps.gov via Sixxs:
 Host  Loss%   Snt   Last
 Avg  Best  Wrst StDev
 1. 2604:8800:100:82bc:ddcb:ae62:e3da:c91f  0.0%160.9
 0.9   0.9   1.6   0.2
 2. gw-701.chi-03.us.sixxs.net  0.0%16   71.6
 72.4  68.6  78.3   2.4
 3. uschi03.sixxs.net   0.0%16   70.2
 71.8  69.2  78.8   2.4
 4. 2620:0:6b0:a::1 0.0%15   67.3
 73.3  67.3  79.7   3.2
 5. tge3-1.fr3.ord4.ipv6.llnw.net   0.0%15   73.6
 75.4  70.1  85.4   4.9
 6. ve8.fr3.ord.ipv6.llnw.net   0.0%15   73.5
 79.7  72.9  90.4   5.7
 7. 2600:805:41f::5 0.0%15  104.4
 81.9  74.2 104.4   9.0
 8. 2600:806::120.0%15  105.2
 104.0 100.6 109.8   2.9
 9. 2600:806:12f::2e0.0%15  134.5
 135.7 131.4 147.4   4.1
 10. 2620:10f:400e:1::4004   0.0%15  161.5
 145.9 131.5 163.8   9.9
 11. ???
 
 pay.gov has IPv6 address 2605:3100:fffd:100::15
 mtr to pay.gov via Sixxs:
 Host  Loss%   Snt   Last
 Avg  Best  Wrst StDev
 1. 2604:8800:100:82bc:ddcb:ae62:e3da:c91f  0.0%110.9
 0.9   0.7   1.1   0.1
 2. gw-701.chi-03.us.sixxs.net  0.0%11   70.8
 70.9  67.0  74.4   2.2
 3. uschi03.sixxs.net   0.0%11   73.7
 73.7  69.8  90.1   5.6
 4. 2620:0:6b0:a::1 0.0%11   70.6
 73.7  70.4  86.2   5.0
 5. tge3-1.fr3.ord4.ipv6.llnw.net   0.0%11   72.4
 75.6  71.5  82.6   3.2
 6. ve8.fr3.ord.ipv6.llnw.net   0.0%11   76.1
 79.3  74.7  87.9   4.0
 7. tge32-3.fr3.dal.ipv6.llnw.net   0.0%11   99.1
 100.1  96.4 106.2   2.7
 8. sl-st30-dal-te0-14-0-1.v6.sprintlink.net0.0%11   98.2
 102.0  98.2 111.0   4.4
 9. sl-crs1-fw-be40.v6.sprintlink.net   0.0%11   99.5
 100.5  96.2 105.5   2.5
 10. sl-gw38-fw-po0-0.v6.sprintlink.net  0.0%11   96.4
 98.8  96.4 105.1   2.6
 11. 2600:4:2000:4::90.0%11  100.2
 102.0  99.0 107.0   2.7
 12. ???
 
 I was hoping an eftps.gov or pay.gov employee was casting an eye this
 way, but it doesn't look like anybody from there is subscribed to
 NANOG.
 
 ...Todd
 -- 
 The total budget at all receivers for solving senders' problems is $0.
 If you want them to accept your mail and manage it the way you want,
 send it the way the spec says to. --John Levine
 -- 
 Mark Andrews, ISC
 1 Seymour St., Dundas Valley, NSW 2117, Australia
 PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: pay.gov and IPv6

[Matthew Kaufman]

On 3/17/2014 11:43 AM, Matthew Kaufman wrote:
Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov 
fail when clients have IPv6 enabled. Work fine if IPv6 is off. One 
more set of client computers that should be dual-stacked are now 
relegated to IPv4-only until someone remembers to turn it back on for 
each of them... sigh.


Matthew Kaufman


Still broken, 7 months later. And again, I was too busy trying to pay to 
try to pull a full set of logs. But if you do something on the FCC site 
that requires payment, the redirection flow dies halfway through if 
you're coming from IPv6 and works fine if you turn it off... so yet 
another computer in the house has IPv6 disabled until manually turned 
back on.


Matthew Kaufman

Re: Book / Literature Recommendations

[Matthew Kaufman]

Patterns in Network Architecture

You might not agree with it, but it does stimulate some thinking.

Matthew Kaufman

(Sent from my iPhone)

 On Sep 16, 2014, at 10:48 AM, James Bensley jwbens...@gmail.com wrote:
 
 Hi All,
 
 What is the single best book you have read on networking? That's a
 wide topic so to clarify I'm talking about service provider networking
 but I do enjoy all aspects really and don't want to limit my self to
 one area of networking.
 
 I'm often reading technical books about technology X or protocol Y but
 they are generally explaining a new technology to me, how it works and
 how to use it (and how to configure it if its a book by a vendor like
 Juniper or Cisco). That is usually a learning exercise though required
 for an upcoming project or deliverable.
 
 I haven't read many vendor neutral books recently that explained
 concepts, or technologies, or paradigms that I found profound, radical
 and extremely useful.
 
 I feel like I'm just reading networking books these days to learn a
 new technology for a period of time (until a project completes) then
 moving on to the next technology (book). Longevity of the information
 doesn't seem as profound as it used to; BGP design principals will
 stay with me for decades until we reach the need for BGP v5 or
 similar, learning about 8b/10b encoding was interesting but not really
 required for my line of work more out of hobbyist interest and serves
 no practical purpose as a network engineer.
 
 
 Cheers,
 James.

Re: Prefix hijacking, how to prevent and fix currently

[Matthew Kaufman]

You're funny. What percentage of legacy holders have or will sign the LRSA do 
you suppose?

Matthew Kaufman

(Sent from my iPhone)

 On Aug 29, 2014, at 3:39 PM, Rob Seastrom r...@seastrom.com wrote:
 
 
 Matthew Kaufman matt...@matthew.at writes:
 
 I look forward to the ARIN fee schedule for legacy IPv4 holder RPKI
 registrations.
 
 I'd assume that it would be included in your annual LRSA maintenance
 fees.
 
 -r
 

Re: Prefix hijacking, how to prevent and fix currently

[Matthew Kaufman]

I look forward to the ARIN fee schedule for legacy IPv4 holder RPKI 
registrations.

Matthew Kaufman

(Sent from my iPhone)

 On Aug 28, 2014, at 8:28 PM, Mark Andrews ma...@isc.org wrote:
 
 
See whois -r AS43239.
 
The long term solution is to deploy RPKI and only use
transits which use RPKI.  No RPKI support = no business.
Additionally make RPKI a peering requirement.
 
Mark
 
 In message 
 CAAjbWEr_o+yQY1T72JMvJ_Nw2Eu2L7=TzZ0dc33mhodo5JB=y...@mail.gmail.com
 , Tarun Dua writes:
 AS Number 43239
 AS Name SPETSENERGO-AS SpetsEnergo Ltd.
 
 Has started hijacking our IPv4 prefix, while this prefix was NOT in
 production, it worries us that it was this easy for someone to hijack
 it.
 
 http://bgp.he.net/AS43239#_prefixes
 
 103.20.212.0/22 - This belongs to us.
 
 103.238.232.0/22 KNS Techno Integrators Pvt. Ltd.
 193.43.33.0/24 hydrocontrol S.C.R.L.
 193.56.146.0/24 TRAPIL - Societe des Transports Petroliers par Pipeline
 
 Where do we complain to get this fixed.
 
 -Tarun
 AS132420
 -- 
 Mark Andrews, ISC
 1 Seymour St., Dundas Valley, NSW 2117, Australia
 PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Akamai charges for IPv6 support?

[Matthew Kaufman]

I guess you expect infrastructure to build itself for free?

Matthew Kaufman

Sent from my iPad

 On Aug 18, 2014, at 7:30 PM, Alejandro Acosta 
 alejandroacostaal...@gmail.com wrote:
 
 
 
 El 8/18/2014 12:23 PM, Aaron Hopkins escribió:
 On Mon, 18 Aug 2014, Mehmet Akcin wrote:
 
 What did they say when you asked them(Akamai)?
 
 I quoted their response in my mail; sorry if that wasn't clear.  They
 offered to enable IPv6 service for a non-trivial monthly recurring fee,
 which they offered to send me a revised contract to include.
 
 it's so sad to hear this in August 2014
 
 
 I would imagine ipv6 to be included in price not an additional fee.
 
 I was surprised to find that wasn't the case.
 
-- Aaron

Re: Muni Fiber and Politics

[Matthew Kaufman]

On 8/6/2014 9:39 AM, Owen DeLong wrote:


So is what I am proposing. In fact, I'm pretty sure my proposal is cheaper, 
especially in the long run.




So build one already!

Matthew Kaufman

Re: Remooted: a deployment design for Muni Fiber (was Re: Muni Fiber and Politics)

[Matthew Kaufman]

Is there any way we could stop this discussion until we can get some 
participants who have experience doing things like emergency 
post-ice-storm overhead circuit restoration to show up and explain 
exactly why charging a small one-time fee for a fiber from A to Z is 
probably not a sustainable model?


In the meantime, I'd like to see the city where an ISP can buy as many 
of the microducts as they want. I'd like to buy them all, please... 
though I have no intention of running anything though them, as I'm an 
investor in the local cable TV company.


Matthew Kaufman

Re: Muni Fiber and Politics

[Matthew Kaufman]

I think the difference is when the municipality starts throwing in free or 
highly subsidized layer 3 connectivity free with every layer 1 connection

Matthew Kaufman

(Sent from my iPhone)

 On Jul 21, 2014, at 12:08 PM, Blake Dunlap iki...@gmail.com wrote:
 
 My power is pretty much always on, my water is pretty much always on
 and safe, my sewer system works, etc etc...
 
 Why is layer 1 internet magically different from every other utility?
 
 -Blake
 
 On Mon, Jul 21, 2014 at 1:38 PM, William Herrin b...@herrin.us wrote:
 On Mon, Jul 21, 2014 at 10:20 AM, Jay Ashworth j...@baylink.com wrote:
 Over the last decade, 19 states have made it illegal for municipalities
 to own fiber networks
 
 Hi Jay,
 
 Everything government does, it does badly. Without exception. There
 are many things government does better than any private organization
 is likely to sustain, but even those things it does slowly and at an
 exorbitant price.
 
 Muni fiber is a competition killer. You can't beat city hall; once
 built it's not practical to compete, even with better service, so
 residents are stuck with only the overpriced (either directly or via
 taxes), usually underpowered and always one-size-fits-all network
 access which results. As an ISP I watched something similar happen in
 Altoona PA a decade and a half ago. It was a travesty.
 
 The only exception I see to this would be if localities were
 constrained to providing point to point and point to multipoint
 communications infrastructure within the locality on a reasonable and
 non-discriminatory basis. The competition that would foster on the
 services side might outweigh the damage on the infrastructure side.
 Like public roads facilitate efficient transportation and freight
 despite the cost and potholes, though that's an imperfect simile.
 
 Regards,
 Bill Herrin
 
 
 --
 William Herrin  her...@dirtside.com  b...@herrin.us
 Owner, Dirtside Systems . Web: http://www.dirtside.com/
 Can I solve your unusual networking challenges?

Re: Muni Fiber and Politics

[Matthew Kaufman]

I'd rather ask Adobe, since their peer-to-peer transport (and layers 
above) has been dual-stacked since it was first designed.


Matthew Kaufman

On 7/21/2014 1:24 PM, Owen DeLong wrote:

Ask Skype just how easy it is to do that with a dual-stacked service.

Owen

On Jul 21, 2014, at 10:29 , Jason Iannone jason.iann...@gmail.com wrote:


Seems like as good at time as any for Netflix to go distributed peer to peer.

On Mon, Jul 21, 2014 at 11:13 AM, Jay Ashworth j...@baylink.com wrote:

Is anyone else cynical enough to say FiOS going symmetrical is an attempt to
blunt the pro-NetFlix argument on that point?
- jra



On July 21, 2014 12:46:27 PM EDT, Jason Iannone jason.iann...@gmail.com
wrote:

There was a muni case in my neck of the woods a couple of years ago.
Comcast spent an order of magnitude more than the municipality but
still lost.

Anyway, follow the money.  Blackburn’s largest career donors are ..
PACs affiliated with ATT ... ($66,750) and Comcast ... ($36,600). ...
Blackburn has also taken $56,000 from the National Cable 
Telecommunications Association.


http://www.muninetworks.org/content/media-roundup-blackburn-amendment-lights-newswires

In other news, FIOS has gone symmetrical.

http://newscenter.verizon.com/corporate/news-articles/2014/07-21-fios-upload-speed-upgrade/

On Mon, Jul 21, 2014 at 8:20 AM, Jay Ashworth j...@baylink.com wrote:

Over the last decade, 19 states have made it illegal for municipalities
to own fiber networks -- encouraged largely, I am told, by Verizon and
other cable companies/MSOs[1].

Verizon, of course, isn't doing any new FiOS deployments, per a 2010
press release[2].

FCC Chair Tom Wheeler has been making noises lately that he wants the
FCC
to preempt the field on this topic, making such deployments legal.

Congressional Republicans think that's a bad idea:


http://www.vox.com/2014/7/20/5913363/house-republicans-and-obamas-fcc-are-at-war-over-city-owned-internet

[ and here's the backgrounder on the amendment:


http://www.broadcastingcable.com/news/washington/blackburn-bill-would-block-fcc-preemption/132468
]

While I generally try to avoid bringing up topics on NANOG that are
political;
this one seems to be directly in our wheelhouse, and unavoidably
political.
My apologies in advance; let's all try to be grownups, shall we?

Cheers,
-- jra

[1]
http://motherboard.vice.com/read/hundreds-of-cities-are-wired-with-fiberbut-telecom-lobbying-keeps-it-unused
[2]
https://secure.dslreports.com/shownews/Verizon-Again-Confirms-FiOS-Expansion-is-Over-118949
--
Jay R. Ashworth
Baylink
  j...@baylink.com
Designer The Things I Think
RFC 2100
Ashworth  Associates   http://www.bcp38.info  2000 Land
Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727
647 1274


--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: Muni Fiber and Politics

[Matthew Kaufman]

Is that what I said?

Matthew Kaufman

On 7/21/2014 1:26 PM, Aaron wrote:
Do you have an example of a municipality that gives free internet 
access to it's residents?



On 7/21/2014 2:26 PM, Matthew Kaufman wrote:
I think the difference is when the municipality starts throwing in 
free or highly subsidized layer 3 connectivity free with every layer 
1 connection


Matthew Kaufman

(Sent from my iPhone)


On Jul 21, 2014, at 12:08 PM, Blake Dunlap iki...@gmail.com wrote:

My power is pretty much always on, my water is pretty much always on
and safe, my sewer system works, etc etc...

Why is layer 1 internet magically different from every other utility?

-Blake

On Mon, Jul 21, 2014 at 1:38 PM, William Herrin b...@herrin.us 
wrote:
On Mon, Jul 21, 2014 at 10:20 AM, Jay Ashworth j...@baylink.com 
wrote:
Over the last decade, 19 states have made it illegal for 
municipalities

to own fiber networks

Hi Jay,

Everything government does, it does badly. Without exception. There
are many things government does better than any private organization
is likely to sustain, but even those things it does slowly and at an
exorbitant price.

Muni fiber is a competition killer. You can't beat city hall; once
built it's not practical to compete, even with better service, so
residents are stuck with only the overpriced (either directly or via
taxes), usually underpowered and always one-size-fits-all network
access which results. As an ISP I watched something similar happen in
Altoona PA a decade and a half ago. It was a travesty.

The only exception I see to this would be if localities were
constrained to providing point to point and point to multipoint
communications infrastructure within the locality on a reasonable and
non-discriminatory basis. The competition that would foster on the
services side might outweigh the damage on the infrastructure side.
Like public roads facilitate efficient transportation and freight
despite the cost and potholes, though that's an imperfect simile.

Regards,
Bill Herrin


--
William Herrin  her...@dirtside.com b...@herrin.us
Owner, Dirtside Systems . Web: http://www.dirtside.com/
Can I solve your unusual networking challenges?

Re: Verizon Public Policy on Netflix

[Matthew Kaufman]

On 7/13/2014 12:54 PM, na...@brettglass.com wrote:


However, if there is any concern about either a Netflix server OR an
ISP's cache being used to obtain illicit copies of the video, the 
solution
is simple. This is a trivial problem to solve. Send and store the 
streams in

encrypted form, passing a decryption key to the user via a separate,
secured channel such as an HTTPS session. Then, it is not possible to 
obtain

usable copies of the content by stealing either a Netflix server OR an
ISP-owned cache. Problem solved.


Unless of course you've promised the content owner that you would be 
encrypting each delivery with a different key (because they'd been 
burned before by things like DVDs, which do not). Then not problem 
solved at all.


You're also assuming that every customer is viewing the same 
bitrate/resolution/aspect ratio. With multi-bitrate streaming, there's 
often low overlap between the segments adjacent customers wish to 
load... even if the content is not encrypted, or is encrypted with the 
same DRM key for everyone.


Of course, the facts of the situation don't appear to matter really...

Matthew Kaufman

Re: Inevitable death, was Re: Verizon Public Policy on Netflix

[Matthew Kaufman]

If you're an ISP and you can't afford even the highest price per IP on 
that list, you have bigger problems than how much it costs to bring 
Netflix traffic to your customers.


Matthew Kaufman

On 7/15/2014 7:58 AM, Brett Glass wrote:

Matt:

Here's the thing. With physical goods, there are economies of scale in
shipping and delivering them in bulk. But IP addresses are simply numbers!
Since there's already a base fee to cover the fixed costs, there's no
reason for the cost per IP to be different. And, in fact, good reason
for it not to be. Big carriers waste a lot of IPs compared to little
guys, who get disproportionate scrutiny.

--Brett Glass

At 12:24 AM 7/15/2014, Matt Palmer wrote:
  

While the share of revenue argument is bogus (as John's cup-of-coffee
analogy made clear), you do have a point with the cost-per-IP-address
argument:

Annual Fee   Max CIDR$/IP
$500 /22 0.49
$1000/20 0.24
$2000/18 0.12
$4000/16 0.06
$8000/14 0.03
$16000   /12 0.02
$32000/12   Mastercard!

Then again, the vast majority of businesses have discounts for volume
purchases.

Re: Verizon Public Policy on Netflix

[Matthew Kaufman]

 traffic to attract the attention of 
CDNs that wish to place content closer to them... so I guess the real 
question is: who forced you to keep your ISP small and local, instead of 
growing it into a major national or international player? My guess: 
Nobody but you yourself made that decision.


Smaller competitors almost always are forced to compete on dimensions 
other than those that economies of scale bring... I'm sure there's a 
small handcrafted furniture shop in Laramie, and I'm sure their 
furniture costs a lot more to make than what Wal-Mart is buying from 
their Chinese supplier. That was their choice... to start and run a 
business that can't take advantage of economies of scale and leverage 
that their competition has, because they've deliberately chosen to *not* 
grow that way. Adopt their mindset, take a deep breath, and maybe you'll 
enjoy being a local small business owner, instead of someone the entire 
universe is apparently trying to crush.



  If Netflix wants us to do that,
it is going to have to pay us, as it pays Comcast.


Have you considered that maybe Netflix doesn't want to do that? Maybe 
they really just don't care if performance to your customers is 
guaranteed. Maybe that's because they know your customers are already so 
used to being hobbled by other restrictions on the use of their Internet 
service that they figure they won't care about Netflix performance. 
Maybe it is because they have millions of other customers who they can 
solve performance issues from more efficiently by improving performance 
to major carriers. Maybe they just haven't gotten around to your ISP 
yet. Maybe they hate Wyoming.


That's their business. You want them to pay you, grow your ISP into 
something they care about.



  That's only fair,
because we would be doing something special just for it -- something
which costs money.


You're free to make infrastructure improvements that improve your 
customers' ability to access Internet services whenever you like. Or to 
fail to do so... and see if they like you enough to not switch to the 
competition who has.


Me, I can't wait until Google Fiber shows up in your town.



If Netflix tries to use its market power to harm ISPs, or to smear
us via nasty on-screen messages as it has been smearing Verizon, ISPs have
no choice but to react.


Oh brother... another reaction to yet another novel use of the 
Internet that you didn't originally design your ISP to handle. Have you 
considered just doing the engineering instead of complaining?



  One way we could do this -- and I'm strongly
considering it -- is to start up a competing streaming service that
IS friendly to ISPs. It would use the minimum possible amount of
bandwidth, make proper use of caching, and -- most importantly --
actually PAY Internet service providers, instead of sapping their
resources, by allowing them to sell it and keep a portion of the fee.
This would provide an automatic, direct, per-customer reimbursement
to the ISP for the cost of bandwidth. ISPs would sign on so fast
that such a service could BURY Netflix in short order.


I wish you luck with this venture. You would undoubtedly learn a lot 
about the costs Netflix has experienced while gaining the right to 
stream (and now create) content that users want to see.


But since complaining about the latest thing is so much easier, I expect 
we'll see a lot more of that instead of this service.


Matthew Kaufman

ps. Please read my background before claiming in your response that I 
don't know anything about {starting and running a small ISP in the early 
1990s, operating a nationwide ISP/CLEC and associated backbone with 
significant peering, owning and operating a wireless ISP, peer-to-peer 
content delivery, video CDNs, Skype}

Re: Ars Technica on IPv4 exhaustion

[Matthew Kaufman]

My Apple TV appears to use IPv6, but since there's no UI for it (last I 
checked) I had to disable SLAAC on that subnet to keep it from trying to use my 
slow connection.

So in my book, some v6 support is actually worse than none

Matthew Kaufman

(Sent from my iPhone)

On Jun 18, 2014, at 1:09 PM, Owen DeLong o...@delong.com wrote:

 
 However, I also don't think consumer education is the answer:
 http://www.wleecoyote.com/blog/consumeraction.htm
 Summary: Until it is perfectly clear why a consumer needs IPv6, and what
 they need to do about it, consumer education will only cause fear and
 frustration, which will not be helpful. This is a technology problem, not
 a feature problem, and consumers shouldn't have to select which Internet
 to be on.
 
 Lee
 
 Short of consumer education, how do you expect to resolve the issue where 
 $CONSUMER walks into $BIG_BOX_CE_STORE and says I need a router, what's the 
 cheapest one you have?
 
 Whereupon $TEENAGER_MAKING_MINIMUM_WAGE who likely doesn't know DOCSIS 2 from 
 DOCSIS 3, has no idea what IP actually is, and thinks that Data is an android 
 from Star Trek says Here, this Linksys thing is only $30.
 
 Unless/until we either get the stores to pull the IPv4-only stuff off their 
 shelves or educate consumers, the continued deployment of additional 
 incapable equipment will be a continuing problem. As bad as the situation is 
 for cablemodems and residential gateways, at least there, an educated 
 consumer can make a good choice. Now, consider DVRs, BluRay players, 
 Receiver/Amplifiers, Televisions, etc. where there are, currently, no IPv6 
 capable choices available to the best of my knowledge.
 
 Owen
 

Re: New Zealand Spy Agency To Vet Network Builds, Provider Staff

[Matthew Kaufman]

No, they just intercept whatever gear you do purchase before it gets to your 
loading dock and then seal it back up with their modifications.

Matthew Kaufman

(Sent from my iPhone)

 On May 13, 2014, at 11:01 AM, Owen DeLong o...@delong.com wrote:
 
 I didn’t see the NSA telling us what we had to buy are demanding advance 
 approval rights on our maintenance procedures.
 
 Owen
 
 On May 13, 2014, at 9:34 AM, Patrick W. Gilmore patr...@ianai.net wrote:
 
 Don't get me wrong, I'm not a fan of this. But at least they did it in the 
 open, unlike the NSA (where you live).
 
 -- 
 TTFN,
 patrick
 
 On May 13, 2014, at 12:12 , Owen DeLong o...@delong.com wrote:
 
 Yep… If I had infrastructure in NZ, that would be enough to cause me to 
 remove it.
 
 Owen
 
 On May 13, 2014, at 6:33 AM, Paul Ferguson fergdawgs...@mykolab.com 
 wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 I realize that New Zealand is *not* in North America (hence NANOG),
 but I figure that some global providers might be interested here.
 
 This sounds rather... dire (probably not the right word).
 
 The new Telecommunications (Interception Capability and Security) Act
 of 2013 is in effect in New Zealand and brings in several drastic
 changes for ISPs, telcos and service providers. One of the country's
 spy agencies, the GCSB, gets to decide on network equipment
 procurement and design decisions (PDF), plus operators have to
 register with the police and obtain security clearance for some staff.
 Somewhat illogically, the NZ government pushed through the law
 combining mandated communications interception capabilities for law
 enforcement, with undefined network security requirements as decided
 by the GCSB. All network operators are subject to the new law,
 including local providers as well as the likes of Facebook, Google,
 Microsoft, who have opposed it, saying the new statutes clash with
 overseas privacy legislation.
 
 http://yro.slashdot.org/story/14/05/13/005259/new-zealand-spy-agency-to-vet-network-builds-provider-staff
 
 FYI,
 
 - - ferg
 
 
 
 - -- 
 Paul Ferguson
 VP Threat Intelligence, IID
 PGP Public Key ID: 0x54DC85B2
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.22 (MingW32)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
 
 iF4EAREIAAYFAlNyHw4ACgkQKJasdVTchbLwDgD/WVHo2iTapJ90l8MRcwUZ5OQ7
 QfJ5cI1v4t2bUXZp1hQBAKHCP0hyxg6naGOzRLt/vHjgxXnl3+yiWoj0ENxQyIr9
 =0yLu
 -END PGP SIGNATURE-
 

Re: Requirements for IPv6 Firewalls

[Matthew Kaufman]

Ignoring security, A is superior because I can change it to DNAT to the new 
server, or DNAT to the load balancer now that said server needs 10 replicas, 
etc. 

B requires re-numbering the server or *if* I am lucky enough that it is reached 
by DNS name and I can change that DNS promptly, assigning a new address and 
adding another firewall rule that didn't exist.

Matthew Kaufman

(Sent from my iPhone)

 On Apr 18, 2014, at 3:19 PM, Eugeniu Patrascu eu...@imacandi.net wrote:
 
 On Fri, Apr 18, 2014 at 6:02 PM, William Herrin b...@herrin.us wrote:
 
 On Fri, Apr 18, 2014 at 3:31 AM, Eugeniu Patrascu eu...@imacandi.net
 wrote:
 On Thu, Apr 17, 2014 at 11:45 PM, George Herbert 
 george.herb...@gmail.com
 wrote:
 You are missing the point.
 
 Granted, anyone who is IPv6 aware doing a green-field enterprise
 firewall
 design today should probably choose another way than NAT.
 
 That's why you have gazzilions of IP addresses in IPv6, so you don't
 need to
 NAT anything (among other things). I don't understand why people cling to
 NAT stuff when you can just route.
 
 4. Defense in depth is a core principle of all security, network and
 physical. If you don't practice it, your security is weak. Equipment
 which is not externally addressable (due to address-overloaded NAT)
 has an additional obstruction an adversary must bypass versus an
 identical system where the equipment is externally addressable (1:1
 NAT, static port translation and simple routing). This constrains the
 kinds of attacks an adversary may employ.
 Let's make it simple:
 
 Scenario (A) w/ IPv4
 [Internet] - Firewall Public IP :80/TCP - DNAT to Internal IP Address
 :80/TCP
 
 Scenario (B) w/ IPv6
 [Internet] - FIrewall - Host w/ Routable IP Address :80/TCP
 
 
 In scenario (A) I hide a server behind a firewall and to a simple
 destination NAT (most common setup found in all companies).
 In scenario (B) I have a firewall rule that only allows port 80 to a
 machine in my network.
 
 
 Explain to me how from a security standpoint Scenario (A) is better than
 scenario (B).
 
 
 Defense in depth, to my knowledge - and feel free to correct me, is to have
 defenses at every point in the network and at the host level to protect
 against different attack vectors that are possible at those points. For
 example a firewall that understands traffic at the protocol level, a
 hardened application server, a hardened application, secure coding
 practices and so on depending of the complexity of the network and the
 security requirements.
 
 
 Feel free to refute all four points. No doubt you have arguments you
 personally find compelling. Your arguments will fall on deaf ears. At
 best the arguments propose theory that runs contrary to decades of
 many folks' experience. More likely the arguments are simply wrong.
 Just because some people have decades of experience, it doesn't mean they
 are right or know what they are doing.
 
 
 Eugeniu

Re: Requirements for IPv6 Firewalls

[Matthew Kaufman]

On 4/17/2014 1:45 PM, George Herbert wrote:
This is why listening to operators is important. 


Why start now? After all, most of the useful input operators could have 
provided would have been much more useful at the beginning.


Matthew Kaufman

Re: Requirements for IPv6 Firewalls

[Matthew Kaufman]

While you're at it, the document can explain to admins who have been burned, 
often more than once, by the pain of re-numbering internal services at static 
addresses how IPv6 without NAT will magically solve this problem.

Matthew Kaufman

(Sent from my iPhone)

 On Apr 17, 2014, at 4:20 PM, Brandon Ross br...@pobox.com wrote:
 
 On Thu, 17 Apr 2014, Sander Steffann wrote:
 
 Also, I note your draft is entitled Requirements for IPv6 Enterprise
 Firewalls. Frankly, no enterprise firewall will be taken seriously
 without address-overloaded NAT. I realize that's a controversial
 statement in the IPv6 world but until you get past it you're basically
 wasting your time on a document which won't be useful to industry.
 
 I disagree. While there certainly will be organisations that want such a 
 'feature' it is certainly not a requirement for every (I hope most, but I 
 might be optimistic) enterprises.
 
 And I not only agree with Sander, but would also argue for a definitive 
 statement in a document like this SPECIFICALLY to help educate the enterprise 
 networking community on how to implement a secure border for IPv6 without the 
 need for NAT.  Having a document to point at that has been blessed by the 
 IETF/community is key to helping recover the end-to-end principle.  Such a 
 document may or may not be totally in scope for a firewall document, but 
 should talk about concepts like default-deny inbound traffic, stateful 
 inspection and the use of address space that is not announced to the Internet 
 and/or is completely blocked at borders for all traffic.
 
 Heck, we could even make it less specific to IPv6 and create a document that 
 describes these concepts and show how NAT is not necessary nor wise for IPv4, 
 either.  (Yes, yes, other than address conservation.)
 
 -- 
 Brandon Ross  Yahoo  AIM:  BrandonNRoss
 +1-404-635-6667ICQ:  2269442
 Skype:  brandonross
 Schedule a meeting:  http://www.doodle.com/bross
 

Re: Requirements for IPv6 Firewalls

[Matthew Kaufman]

I think I got you to say NAT

Matthew Kaufman

(Sent from my iPhone)

 On Apr 17, 2014, at 7:05 PM, Timothy Morizot tmori...@gmail.com wrote:
 
 
 On Apr 17, 2014 7:52 PM, Matthew Kaufman matt...@matthew.at wrote:
 
  While you're at it, the document can explain to admins who have been 
  burned, often more than once, by the pain of re-numbering internal services 
  at static addresses how IPv6 without NAT will magically solve this problem.
 
 If you're worried about that issue, either get your own end user 
 assignment(s) from ARIN or use ULA internally and employ NAT-PT (prefix 
 translation) at the perimeter. That's not even a hard question.

pay.gov and IPv6

[Matthew Kaufman]

Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov fail 
when clients have IPv6 enabled. Work fine if IPv6 is off. One more set 
of client computers that should be dual-stacked are now relegated to 
IPv4-only until someone remembers to turn it back on for each of them... 
sigh.


Matthew Kaufman

Re: pay.gov and IPv6

[Matthew Kaufman]

Windows 8 running Google Chrome as the browser.

Matthew Kaufman

On 3/17/2014 11:46 AM, Arturo Servin wrote:


No Happy Eyeballs?

Perhaps also time to ditch XP and IE for something new as well.

-as




On Mon, Mar 17, 2014 at 11:43 AM, Matthew Kaufman matt...@matthew.at 
mailto:matt...@matthew.at wrote:


Random IPv6 complaint of the day: redirects from FCC.gov to
pay.gov http://pay.gov fail when clients have IPv6 enabled. Work
fine if IPv6 is off. One more set of client computers that should
be dual-stacked are now relegated to IPv4-only until someone
remembers to turn it back on for each of them... sigh.

Matthew Kaufman

Re: pay.gov and IPv6

[Matthew Kaufman]

It was reachable by hand-typed URL, but the machines trying to follow a 
redirect from the FCC site during payment flow failed. Had to be brought back 
online, so once it was determined that turning v6 off was sufficient, that was 
the end if the debugging.

Matthew Kaufman

(Sent from my iPhone)

 On Mar 17, 2014, at 1:02 PM, Jared Mauch ja...@puck.nether.net wrote:
 
 One more (498?) set(s) of data points:
 
 I used RIPE ATLAS probes to check the SSL certificate over IPv6 (a nice way 
 to check reachability)..
 
 Measurement# 1584700
 
 You can look through the data to determine where it's not reachable from, but 
 it seems to be generally reachable without issue from nearly all the probes.
 
 JSON link as well:
 
https://atlas.ripe.net/api/v1/measurement/1584700/result/
 
 - Jared
 
 On Mar 17, 2014, at 3:35 PM, Jared Mauch ja...@puck.nether.net wrote:
 
 No issues for me over IPv6 on Comcast.
 
 Perhaps some local network issue?  Any reported issues if you try to visit 
 http://www.test-ipv6.com/ ?
 
 - Jared
 
 On Mar 17, 2014, at 2:55 PM, Matthew Kaufman matt...@matthew.at wrote:
 
 Windows 8 running Google Chrome as the browser.
 
 Matthew Kaufman
 
 On 3/17/2014 11:46 AM, Arturo Servin wrote:
 
 No Happy Eyeballs?
 
 Perhaps also time to ditch XP and IE for something new as well.
 
 -as
 
 
 
 
 On Mon, Mar 17, 2014 at 11:43 AM, Matthew Kaufman matt...@matthew.at 
 mailto:matt...@matthew.at wrote:
 
  Random IPv6 complaint of the day: redirects from FCC.gov to
  pay.gov http://pay.gov fail when clients have IPv6 enabled. Work
  fine if IPv6 is off. One more set of client computers that should
  be dual-stacked are now relegated to IPv4-only until someone
  remembers to turn it back on for each of them... sigh.
 
  Matthew Kaufman