Re: IPv4 and Auctions

[Lee Howard]

On 10/27/19 12:47 PM, Michel Py wrote:



Michel Py wrote :
What I like with Hilco is that it brings transparency to the market. I think 
that each transfer should list the amount of the
transaction between parties. For example, I would like to know for how much 
44.192/10 went.


The parties to transactions probably protect that data in the same way 
they protect how much they paid for their routers, software licenses, 
and payroll.




Owen DeLong wrote :
If you really feel that this should be data the RIRs collect during transfers 
and that it should be published, I suggest you submit a proposal
for this into the ARIN policy development process. If you need help doing so, 
feel free to ask me or any other member of the AC.

I think the result should be simple, a .csv file containing an entry for each 
prefix transferred :
Date, size, price, origin RIR, resulting RIR.
Something like https://auctions.ipv4.global/prior-sales but covering all 
transactions, not only ipv4.global ones.
Transparency on transfer prices.


Other than price, each of the RIRs publishes all of that information in 
a daily transfers report. Maybe JSON instead of CSV, and they don't all 
use the same dictionary, but it's public.


Anyone can list blocks on auctions.ipv4.global, and the transaction will 
be included in our prior-sales report. Even private transactions can be 
run through the site, with the side benefit of including the transaction 
in that report.


Some brokers use the platform when they have a buyer who needs space and 
they don't have the right block, or they have a seller and want broader 
reach. If other brokers, buyers, or sellers were interested in 
publishing their transaction data, we'd happily do it.





What do you think about it ? a two-prong question :

- As yourself ? is it desirable for the community  in your opinion ?

- As AC member ? Does it have any chance to be approved by the AC ?

I would submit a proposal if it has some chances to pass; I don't want to lose 
the time of the AC if it's going to be deep-sixed right away.


This Thursday afternoon, at the end of the ARIN public policy meeting, 
is open mic time. If you want to float an idea to get the community's 
first impression, that's a pretty good time.


Lee

Re: IPv4 and Auctions

[Lee Howard]

Since you mentioned Hilco specifically. . .

IPv4.Global is the IPv4 address brokerage operated by Hilco Streambank. 
We match organizations who have more IPv4 address space than they need 
with organizations who need more IPv4 address space than they have. This 
is consistent with ARIN's Number Resource Policy Manual sections 8.3. 
and 8.4 
https://www.arin.net/participate/policy/nrpm/#8-3-transfers-between-specified-recipients-within-the-arin-region


I was on the ARIN Board when we approved this policy in 2008. The 
compelling argument to me was that this market would improve overall 
utilization of address space, and would be more efficient than ARIN 
trying to reclaim unused or lightly used address blocks. There are a lot 
of cases where pre-RIR, the justification was minimal, and 
organizational needs may change over the intervening 20-40 years.


Part of the interest, to me, was that many organizations who had 
received their allocations prior to ARIN's existence did not recognize 
ARIN's authority to reclaim their space. Even if ARIN prevailed in 
court, it would have been costly.


Not only that, but there's no minimum utilization requirement to keep 
addresses. You must show 50-80% utilization to get more, but what if you 
aren't asking for more? Would ARIN reclaim a block that was only 45% 
used? 25%? 1%?


In each of the more than 1500 transfers IPv4.Global has handled, the 
recipient has had to satisfy their need under the rules of the RIR in 
which they operate.


ARIN's policies are established by community consensus. ARIN's Public 
Policy Mailing List (ppml) is open, and there's a designated open 
microphone time at the end of the meeting next Thursday. If you won't be 
there in person, remote participation is pretty good.


I'm always happy to talk about this, either one on one, or if there are 
other folks at NANOG/ARIN next week who want to get together to chat, 
I'd be happy to facilitate.


Lee


On 10/24/19 8:08 AM, Matt Hoppes wrote:

A thought crossed my mind the other day as I was having a discussion with 
someone.

Every entity is suppose to justify their need for IPv4 address space from ARIN. 
This was always (in recent history) the case.

No entity is suppose to be given more IPv4 space until they have nearly 
exhausted their previous space.

How is it, then, that we daily for the last 2-3 years have places like Hilco 
that have sometimes 15-20 large IPv4 blocks up for auction?

Supposedly we are completely out of IPv4 space, yet every day large blocks are 
being sold for money, yet they were never returned because they weren’t needed.

Another thought: being that IPv4 address space is essentially leased to you 
from ARIN, can you even legally auction your space to someone else? I know it’s 
happening, but it would almost be like me auctioning my apartment to another 
random person.

Re: MAP-E

[Lee Howard]

On 8/9/19 1:32 AM, Vincent Bernat wrote:

  ❦  8 août 2019 16:18 -04, Lee Howard :


NAT64. IPv6-only to users. DNS resolver given in provisioning
information is a DNS64 server. When it does a lookup but there's no
, it invents one based on the A record (e.g., 2001:db8:64::). The IPv6 prefix in the invented  is actually a NAT64
translator. Pro: no CPE support required, well understood. Con: No
support for IPv4-only stuff in the prem, breaks DNSSEC.

Is there a known deployment for a medium/large ISP?


Not a fixed/wireline ISP.

The "con" that consumers' game consoles, smart TVs, and IoT things won't 
work is a pretty big "con." I was working with a small ISP that was 
running out of IPv4 addresses, and they kept saying "NAT64." I warned 
them that while NAT64 would solve their runout problem, it would drive a 
lot of unhappy customer calls.


It would be interesting if someone offered a NAT64 service (maybe for a 
reduced price). Buyers could tell consumer electronics companies, "I 
can't use your device without IPv6." But qualifying the customer who 
would do that would be more expensive, I think, than just buying IPv4 
addresses. Also but, would that be a Net Neutrality problem, charging 
less for a service that has arguably worse access to Amazon, Reddit, 
Twitter, etc.?


Lee



Thanks.

Re: MAP-E

[Lee Howard]

On 8/8/19 9:00 PM, Masataka Ohta wrote:

Lee Howard wrote:

MAP-T, MAP-E. IPv6-only between CE and Border Relay (BR). CPE is 
provisioned with an IPv4 address and a range of ports. It does basic 
NAT44, but only uses the reserved ports. Then it translates to IPv6 
(MAP-T) or encapsulates in IPv6 (MAP-E) and forwards to the 
configured Border Relay (BR), which changes it to IPv4. Pro: 
Stateless, very efficient. Con: Very little CPE support in home routers.


So, all we need is NAT44 CPE, which only uses a reserved block of ports,
which is (semi) statically configured by ISP operated gateway.


How would you route from the provider edge?

If CPE A has 192.0.2.15 port 1000-2999

and CPE B has 192.0.2.15 port 3000-4999,

how does your BRAS or CMTS or edge router know whether to forward a 
packet to A or B?


You could do policy routing or similarly do deep packet inspection, but 
you'd need a mechanism to provision that information into the provider 
edge router; you wouldn't manually configure match/set policy for each 
customer.



Pro: Stateless, very efficient, no IPv6 necessary Con: No current
CPE support.

As for protocol, assuming port mapping on UPnP gateway is statically
configured by ISPs not changable from CPE side, GetListOfPortMappings()
of UPnP should be useful for CPEs to know range of ports to be used
by them.


Do CPEs do this now, or is this another feature to ask vendors for?

Lee



    Masataka Ohta

Re: MAP-E

[Lee Howard]

On 8/2/19 11:39 AM, Jay Hanke wrote:

Is there a summary presentation someplace laying out the options that
are active in the wild with some deployment stats?


I can't think of a public presentation off the top of my head that 
explains how each major transition technology works, and the pros and 
cons of each. There must be one, but it's hard to cover the major 
options in an hour.


If you want to know who is using any given transition technology, 
there's this crowd-sourced list:


https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7NK9vcVApc/edit#gid=0

Very brief summary of options:

NAT444. Your basic NAT, plus NAT again. You really need to deploy IPv6, 
too, or all your traffic will go through a translator (everything else 
below assumes native IPv6 is deployed). State information can get 
expensive. Well understood.


Dual-stack Lite. CPE sends IPv4 traffic through an IPv6 tunnel 
(softwire) to a pre-configured DS-Lite box, which does NAT44. Works 
fine, deployed at scale (see sheet above), but keeping state on lots of 
NAT44 can get expensive at scale.


NAT64. IPv6-only to users. DNS resolver given in provisioning 
information is a DNS64 server. When it does a lookup but there's no 
, it invents one based on the A record (e.g., 2001:db8:64::address>). The IPv6 prefix in the invented  is actually a NAT64 
translator. Pro: no CPE support required, well understood. Con: No 
support for IPv4-only stuff in the prem, breaks DNSSEC.


464xlat. IPv6-only between CE and NAT64. Any IPv4 traffic the CPE 
receives, it translates to IPv6 and forwards to a destination that's the 
NAT64 server, which translates again. Pro: widely deployed at scale on 
mobile networks. Con: Very little CPE support in home routers.


MAP-T, MAP-E. IPv6-only between CE and Border Relay (BR). CPE is 
provisioned with an IPv4 address and a range of ports. It does basic 
NAT44, but only uses the reserved ports. Then it translates to IPv6 
(MAP-T) or encapsulates in IPv6 (MAP-E) and forwards to the configured 
Border Relay (BR), which changes it to IPv4. Pro: Stateless, very 
efficient. Con: Very little CPE support in home routers.


Jordi is going to tell me there's plenty of support for 464xlat. 
However, you can't go into any old electronics store in North America 
and buy a home gateway with support for 464xlat or MAP. You can't buy 
them directly from a vendor, unless you're large enough to request a 
specific firmware build. Yes, you can get support from OpenWRT, but 
that's probably not how you want your support team spending their time.


CPE support is the next big frontier in IPv6 deployment.

Lee



On Fri, Aug 2, 2019 at 10:34 AM JORDI PALET MARTINEZ via NANOG
 wrote:

I understand that, but the inconvenient is the fix allocation of ports per 
client, and not all the clients use the same number of ports. Every option has 
good and bad things.



MAP is less efficient in terms of maximizing the “use” of the existing IPv4 
addresses.



https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/





Regards,

Jordi

@jordipalet







El 2/8/19 17:25, "NANOG en nombre de Baldur Norddahl"  escribió:



Hi Jordi



My alternative to MAP-E is plain old NAT 444 dual stack. I am trying to avoid 
the expense and operative nightmare of having to run a redundant NAT server 
setup with thousands of users. MAP is the only alternative that avoids a 
provider run NAT server.



Regards,



Baldur





On Fri, Aug 2, 2019 at 3:38 PM JORDI PALET MARTINEZ via NANOG  
wrote:

Ask the vendor to support RFC8585.



Also, you can do it with OpenWRT.



I think 464XLAT is a better option and both of them are supported by OpenWRT.



You can also use OpenSource (Jool) for the NAT64.



Regards,

Jordi

@jordipalet







El 2/8/19 14:20, "NANOG en nombre de Baldur Norddahl"  escribió:



Hello



Are there any known public deployments of MAP-E? What about CPE routers with 
support?



The pricing on IPv4 is now at USD 20/address so I am thinking we are forced to 
go the CGN route going forward. Of all the options, MAP-E appears to be the 
most elegant. Just add/remove some more headers on a packet and route it as 
normal. No need to invest in anything as our core routers can already do that. 
No worries about scale.



BUT - our current CPE has zero support. We are too small that they will make 
this feature just for us, so I need to convince them there is going to be a 
demand. Alternatively I need to find a different CPE vendor that has MAP-E 
support, but are there any?



What is holding MAP-E back?  In my view MAP-E could be the end game for IPv4. 
Customers get full IPv6 and enough of IPv4 to be somewhat compatible. The ISP 
networks are not forced to do a lot of processing such as CGN otherwise 
requires.



I read some posts from Japan where users are reporting a deployment of MAP-E. 
Anyone know about that?



Regards,



Baldur




**
IPv4 is 

Re: MAP-E

[Lee Howard]

On 8/2/19 1:10 PM, JORDI PALET MARTINEZ via NANOG wrote:


The cost of sharing IPs in a static way, is that services such as Sony 
Playstation Network will put those addresses in the black list, so you 
need to buy more addresses. This hasn’t been the case for 
464XLAT/NAT64, which shares the addresses dynamically.


Furthermore, if some users need less ports than others, you 
“infra-utilize” those addresses, which again is not the case for 
464XLAT/NAT64. Each user gets automatically as many ports as he needs 
at every moment.


So, you save money in terms of addresses, that you can invest in a 
couple of servers running a redundant NAT64 setup 
(https://www.jool.mx/en/session-synchronization.html). Those servers 
can be actually VMs, so you don’t need dedicated hardware, especially 
because when you deploy IPv6 with 464XLAT, typically 75% (and going 
up) of you traffic will be IPv6 and only 25% will go thru the NAT64.


You work on much smaller networks than I do if a "couple of servers 
running Jool" can handle your load.  Jool is great, and the team that 
built it is great, but a couple of 10Gbps NICs on a pizza box doesn't go 
very far. I've tried 100Gbps and can't get the throughput with any 
normal CPU. Hoping to get back to it and run some actual measurements.


Lee


Regards,

Jordi

@jordipalet

El 2/8/19 18:24, "NANOG en nombre de Baldur Norddahl" 
mailto:nanog-boun...@nanog.org> en nombre de 
baldur.nordd...@gmail.com > escribió:


The goal is to minimize cost. Assuming 4 bits for the MAP routing (16 
users sharing one IPv4), leaving 12 bits for customer ports (4096 
ports) and a current price of USD 20 per IPv4 address, this gives a 
cost of USD 1.25 per user for a fully redundant solution. For us it is 
even cheaper as we can recirculate existing address space.


Regards,

Baldur

On Fri, Aug 2, 2019 at 5:32 PM JORDI PALET MARTINEZ 
mailto:jordi.pa...@consulintel.es>> wrote:


I understand that, but the inconvenient is the fix allocation of
ports per client, and not all the clients use the same number of
ports. Every option has good and bad things.

MAP is less efficient in terms of maximizing the “use” of the
existing IPv4 addresses.

https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/

Regards,

Jordi

@jordipalet

El 2/8/19 17:25, "NANOG en nombre de Baldur Norddahl"
mailto:nanog-boun...@nanog.org> en
nombre de baldur.nordd...@gmail.com
> escribió:

Hi Jordi

My alternative to MAP-E is plain old NAT 444 dual stack. I am
trying to avoid the expense and operative nightmare of having to
run a redundant NAT server setup with thousands of users. MAP is
the only alternative that avoids a provider run NAT server.

Regards,

Baldur

On Fri, Aug 2, 2019 at 3:38 PM JORDI PALET MARTINEZ via NANOG
mailto:nanog@nanog.org>> wrote:

Ask the vendor to support RFC8585.

Also, you can do it with OpenWRT.

I think 464XLAT is a better option and both of them are
supported by OpenWRT.

You can also use OpenSource (Jool) for the NAT64.

Regards,

Jordi

@jordipalet

El 2/8/19 14:20, "NANOG en nombre de Baldur Norddahl"
mailto:nanog-boun...@nanog.org> en
nombre de baldur.nordd...@gmail.com
> escribió:

Hello

Are there any known public deployments of MAP-E? What about
CPE routers with support?

The pricing on IPv4 is now at USD 20/address so I am thinking
we are forced to go the CGN route going forward. Of all the
options, MAP-E appears to be the most elegant. Just add/remove
some more headers on a packet and route it as normal. No need
to invest in anything as our core routers can already do that.
No worries about scale.

BUT - our current CPE has zero support. We are too small that
they will make this feature just for us, so I need to convince
them there is going to be a demand. Alternatively I need to
find a different CPE vendor that has MAP-E support, but are
there any?

What is holding MAP-E back?  In my view MAP-E could be the end
game for IPv4. Customers get full IPv6 and enough of IPv4 to
be somewhat compatible. The ISP networks are not forced to do
a lot of processing such as CGN otherwise requires.

I read some posts from Japan where users are reporting a
deployment of MAP-E. Anyone know about that?

Regards,

Baldur


**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be
privileged or confidential. The information is 

Re: any interesting/useful resources available to IPv6 only?

[Lee Howard]

On 5/6/19 12:45 PM, Brian J. Murrell wrote:


But the came I am making is to PHBs, not engineers and I am trying to
find a path of least resistance.


IPv6 is, on average, 20ms faster than IPv4. I don't know why, I just 
know that the evidence is diverse and compelling that it's true. 
https://www.retevia.net/fast


A faster web site means people find it earlier in Google search, stay on 
it longer, and buy more stuff from it. https://www.retevia.net/seo


If you're an ISP, it would be nice to give your customers that extra speed.

IPv6 in your data center also means your security team has an easier 
time tracking down miscreants than if they were behind CGN. Any security 
tool without IPv6 is blind to 54% of US traffic, 24% of CA traffic, 27% 
of global traffic.


Renumbering into IPv6 might mean you can make addresses available for 
sale, and prices are approaching the point where that makes sense. 
https://www.retevia.net/address-pricing-2019-and-beyond/


For ISPs, you should absolutely figure out your IPv4 run rate, i.e., 
when you'll run out of IPv4 addresses. Then the PHBs have to decide what 
to do about that: deploy IPv6 and hope it's a viable alternative (with 
translation?), buy IPv4 addresses (at today's prices or tomorrow's, and 
how many addresses?), or deploy NAT44 and hope customers are okay with it.


For ISPs, consider how many of your customers are medium to large 
companies. These customers may need IPv6, either to sell their own 
addresses, or to connect with branches or partners who are out of IPv4. 
There are ISPs in the world who only support native IPv4 because some of 
their customers can't get approval for IPv4 from US corporate HQ. Of 
course, they pay more for that. For that matter, consider how much you 
charge for additional IPv4 addresses, and the rate at which customers 
could decline that service.


(But wait, you say, PHBs don't want to lose the IPv4 revenue! Depends on 
whether the competition is likely to offer the cheaper alternative)


Finally, the Rabobank argument: Maybe there aren't important sites, 
tools, or architectures that are only available over IPv6 right now. 
When will there be? Five years? Ten? (Seven? 
https://www.retevia.net/ipv6-growth/) How long will it take you to be 
completely IPv4-independent, and will it be done in time?


So there's an 8-slide deck for you. Good luck with that pitch! I'm 
interested in what feedback/pushback you get.


Lee




b.

Re: Auto-configuring IPv6 transition mechanisms on customer devices

[Lee Howard]

On 1/2/19 7:59 AM, Brandon Martin wrote:

On 1/2/19 7:37 AM, Mikael Abrahamsson wrote:


Yes, we're buying devices from a vendor that uses OpenWrt as base for 
their operating system. We're using this one currently:


https://www.intenogroup.com/products/gateways/eg400/

We remotely manage it using Netconf/YANG from our NMS so we can do 
software upgrades (and other management). If you have low volume you 
can of course use SSH and script it if that's what you want. They 
also have TR-69 based management, and perhaps others.


If only Ubiquiti had so many (documented) options for management...


DHCPv6 is fine.

Jordi did a panel a year ago at APNIC where he browbeat vendors about 
supporting transition mechanisms. The summary is that they said they 
have code, they just don't want to ship everything, because it's more to 
maintain. 
https://blog.apnic.net/2017/11/09/ce-vendors-share-thoughts-ipv6-support/


This led to the draft he mentioned upthread, requiring support. OpenWRT 
is still the only thing I've seen that wasn't a customer-specific build.





Get in touch with them, tell them I said hi. They might be able to 
accomodate your low volume by sending you gateways with their default 
software on it and you'd have to upgrade it to whatever image you 
want on it, yourself. It only takes a few minutes per box so should 
be perfectly doable with your low volume

That could work.  I'll give them a shout.  Thanks for the pointer.

Out of curiosity, what do you use to terminate the MAP/LW4o6 
tunnels/encaps to the public Internet?  Plenty of options here, of 
course, especially at the traffic rates I'm moving.  I'm just curious 
what others' experiences have been as these are still somewhat new in 
SP deployments, I think.


Open source software. For stateless transition mechanisms (MAP/LW4o6) it 
can be really fast. We have a build I'd be happy to share, if you want.


Lee

Re: OpenDNS CGNAT Issues

[Lee Howard]

On 09/11/2018 09:31 AM, Matt Hoppes wrote:

So don't CGNat?  Buy IPv4 addresses at auction?


Buy IPv4 addresses until CGN is cheaper. If a customer has to call, and 
you have to assign an IPv4 address, you have to recover the cost of that 
call and address.
While ((CostOfCall + CostOfAddress)*NumberOfCalls) > 
(CostOfAddress*NumberOfNewCustomers):

 BuyAddresses(NumberOfNewCustomers)

Meanwhile, deploy IPv6, and move toward IPv4aaS, probably 464xlat or 
MAP, but your religion may vary. That way your "CGN" is an IPv6-IPv4 
translator, and that's easier than managing dual-stack.


At the very least, dual-stack your web sites now, so the rest of us can 
get to it without translation.


Lee



On 9/11/18 9:28 AM, Ca By wrote:



On Tue, Sep 11, 2018 at 6:04 AM Matt Hoppes 
> wrote:


    That isn’t a solution. He still will need to dual stack and CGNat 
that.



But the flows that can support ipv6, will go ipv6 and not be subject 
to these abuse triggers.


Look, this list has monthly reports from some small network operator 
hurting their customers with CGN NAT. Meanwhile, the big guys like 
Comcast / Charter / ATT / Cox have moved onto ipv6.


Where does that leave the little guy with CGN?

Right here. Screaming into the avoid begging for help. Some special 
exception.


And, me, saying you had 10+ years of not deploying ipv6.  Here’s to 
the next 10 years of you email this list about your own failure to 
keep up with the times.


We will have this discussion again and again.  Not sure your 
customers will stick around, all they know is your CGN space got 
black listed from yet another service


#realtalk


    On Sep 11, 2018, at 08:54, Ca By mailto:cb.li...@gmail.com>> wrote:




    On Mon, Sep 10, 2018 at 9:12 PM Darin Steffl
    mailto:darin.ste...@mnwifi.com>> wrote:

    Hello,

    I have a ticket open with OpenDNS about filtering happening on
    some of our CGNAT IP space where a customer has "claimed" the
    IP as theirs so other customers using that same IP and OpenDNS
    are being filtered and not able to access sites that fall
    under their chosen filter.

    I have a ticket open from 6 days ago but it's not going
    anywhere fast.

    Can someone from OpenDNS contact me or point me to a contact
    there to help get this resolved? I believe we need to claim
    our CGNAT IP space so residential users can't claim IP's of
    their own.

    Thank you!


    You should provide your users ipv6, opendns supports ipv6 and
    likely will not have this issue you see

    https://www.opendns.com/about/innovations/ipv6/

    I am sure it may cost you time / money / effort. But this old
    thing we call ipv4 is in a death spiral, and it will just get
    worse and worse for you without ipv6.




    --     Darin Steffl
    Minnesota WiFi
    www.mnwifi.com 
    507-634-WiFi
     Like us on Facebook
    

Re: at business ipv6

[Lee Howard]

On 06/21/2018 12:07 PM, Nick Hilliard wrote:

Randy Bush wrote on 21/06/2018 16:35:


Static addresses don't fit into this paradigm because you if you 
configure your static customers from a single broadcast domain, then 
they are glued to a particular CMTS and can't be moved from that CMTS 
unless you renumber them.


Completely agree with all you've said here about how DOCSIS works. 
Several cable operators (at least) are working to make it so that DHCPv6 
assigns business customers  the same IPv6 prefix every time. Yes, it's 
DHCPv6 instead of static configuration, but I think it works.


Additional question, though:
Randy said "at business 1g fiber going into an Arris"
As fiber, it'll be PON. If it were a traditional cable company, I'd 
guess DPOE (DOCSIS Provisioning Over Ethernet).
Except it's AT, and I don't know if they're provisioning DOCSIS over 
their fiber; I would think it's GPON, using the same infrastructure as 
their U-Verse product (fiber to the curb, DSL to the home). That used to 
be PPPoE and not DHCP, but my information may be out of date.



Lee

Re: Impacts of Encryption Everywhere (any solution?)

[Lee Howard]

On 06/17/2018 02:53 PM, Brad wrote:

While I agree there are unintended consequences every time advancements are 
made in relation to the security and stability of the Internet- I disagree we 
should be rejecting their implementations. Instead, we should innovate further.


I look forward to your innovations.

Just because end to end encryption causes bandwidth issues for a very small 
number users - then perhaps they could benefit the most by these changes with 
additional capacity.


I encourage you to invest billions of dollars in rural broadband 
capacity worldwide. The rest of us will thank you for your sacrifice.


Lee


-Brad

 Original message From: Michael Hallgren  Date: 
6/17/18  11:14  (GMT-07:00) To: na...@jack.fr.eu.org Cc: Matthew Petach 
, nanog@nanog.org Subject: Re: Impacts of Encryption Everywhere (any 
solution?)
Le 2018-06-17 12:40, na...@jack.fr.eu.org a écrit :

Well, yes, there is, you simply have to break the end to end encryption

Yes, (or) deny service by Policy (remains to evaluate who's happy with
that).

Cheers,
mh


On 06/17/2018 03:09 AM, Matthew Petach wrote:

Except that if websites are set to HTTPS only, there's no option for
disabling encryption on the client side.

Matt


On Sat, Jun 16, 2018, 14:47  wrote:


On 06/16/2018 10:13 PM, Mike Hammett wrote:

Sadly, it's just falling on deaf ears. Silicon Valley will continue
to

think they know better than everyone else and people outside of that
bubble
will continue to be disadvantaged.

What, again ?
Encryption is what is best for the most people.
The few that will not use it can disable it.

No issue then.

Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap

[Lee Howard]

On 06/11/2018 05:16 PM, Scott Weeks wrote:


--- cb.li...@gmail.com wrote:
From: Ca By 


Meanwhile, FB reports that 75% of mobiles in the USA
reach them via ipv6

And Akaimai reports 80% of mobiles

And they both report ipv6 is faster / better.


Let me grab a few more for you:

https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile-networks-why-and-how.html 



https://blogs.akamai.com/2016/10/ipv6-at-akamai-edge-2016.html

https://www.theregister.co.uk/2016/07/28/ipv6_now_faster_a_fifth_of_the_time 
which cites an academic paper 
http://dl.acm.org/citation.cfm?doid=2959424.2959429 by Vaibhav Bajpai 
and Jürgen Schönwälder


https://www.linkedin.com/pulse/ipv6-measurements-zaid-ali-kahn/

https://community.infoblox.com/t5/IPv6-CoE-Blog/Can-IPv6-Rally-Be-Faster-than-IPv4-Part-1/ba-p/6419 



https://www.nanog.org/meetings/abstract?id=2281


I'd sure like to see how they came up with these
numbers in a technically oriented paper.

Most of the above links explain how they got the numbers.
Facebook, in particular, did A/B testing using Mobile Proxygen, which is 
to say that they configured their mobile app to report performance over 
both IPv4 and IPv6 from the same handset at the same time.
Others, including APNIC's https://stats.labs.apnic.net/v6perf have a 
browser fetch two objects with unique URLs, one from an IPv4-only server 
and one from an IPv6-only server, and compare them.





  There
should be no difference, except for no CGN or Happy
Eyeballs working better or something similar.  Am I
missing something?  Same routers; same links; same
RTTs; same interrupt times on servers; same etc, etc
for both protocols.


From time to time somebody says, "Okay, maybe it works in practice, but 
does it work in *theory*?"


Busy engineers hardly ever investigate things going inexplicably right.

My hypothesis is that the observed difference in performance relates to 
how mobile networks deploy their transition mechanisms. Those with a 
dual-stack APN take a native path for IPv6, while using a CGN path for 
IPv4, which, combined with the Happy Eyeballs head start, might add 
501microseconds, which is a ms, which is 15% of 7ms. Those with an 
IPv6-only APN use a native path for IPv6, while using either a NAT64 for 
IPv4 (identical performance to CGN) or 464xlat, which requires 
translation both in the handset and the NAT64; handsets may not be 
optimized for header translation.


However, I have a dozen other hypotheses, and the few experiments I've 
been able to run have not confirmed any hypothesis. For instance, when 
one protocol is faster than another on a landline network, hop count is 
not a correlation (therefore, shorter paths, traffic engineering, etc., 
are not involved).


Lee



Hmm...  Faster and better?

The links seem to be an IPv6 cheerleader write up.
I looked at the URLs and the URLs one pointed to and
pulled out everything related to IPv6 being
faster/better.


Akamai URL:

"For dual-stacked hostnames we typically see higher
average estimated throughput over IPv6 than over IPv4.
Some of this may be due to IPv6-connected users being
correlated with better connectivity, but over half of
dual-stacked hostnames (weighted by daily bytes
delivered) have IPv6 estimated throughput at least 50%
faster than IPv4, and 90% of these hostnames have the
IPv6 estimated throughput at least 10% faster than
IPv4."



FB URL:

"People using Facebook services typically see better
performance over IPv6..."

and it points to
https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-board
which says:

"We’ve long been anticipating the exhaustion of IPv
in favor of the speed and performance benefits of
IPv6."

"We’ve observed that accessing Facebook can be 10-15
percent faster over IPv6."


I'd sure like to see how they came up with these
numbers in a technically oriented paper.  There
should be no difference, except for no CGN or Happy
Eyeballs working better or something similar.  Am I
missing something?  Same routers; same links; same
RTTs; same interrupt times on servers; same etc, etc
for both protocols.

scott

Re: Need /24 (arin) asap

[Lee Howard]

Assuming IPv6+translation, yes, you need IPv4 addresses of Good Repute 
for the outside; that might requiring constant monitoring, and notifying 
various content that it's shared address space. It's the same 
operational problem as CGNAT44, but reduced because half (or more) of 
your traffic is using unshared IPv6. Among other things, that means you 
don't need as many IPv4 addresses.


"But wait!" you say, because you're clever, "The original poster only 
wanted a /24. Surely you're not saying you could put less than a /24 
outside your CGN (44 or 64) and have it routed?"


Maybe the /28 is part of your larger aggregate. Or maybe it's a shared 
translator, handling, say, eight small companies who only need a /28 
each. And yes, you want very careful reputation monitoring in that case, 
and maybe some effort to prevent things that get one placed on Lists of 
Addresses of Ill Repute.


Sales pitch available on demand.

Lee Howard
Retevia.net


On 06/11/2018 12:56 PM, Michael Crapse wrote:

Never do i suggest to not have ipv6! Simply that no matter what, You still
have to traverse to ipv4 when you exit your ipv6 network onto ipv4 only
services. What IPv4 addresses are you going to use for the NAT64, or
464xlat, or even the business customers that require static IPv4 addresses?
Someone made a statement that getting more ipv6 would solve OP's problem of
finding more clean ipv4 space


On 11 June 2018 at 10:50, Ca By  wrote:



On Mon, Jun 11, 2018 at 9:27 AM, Michael Crapse 
wrote:


For an eyeball network, you cannot count on an IPv6 only network. Because
all of your "customers" will complain because they can't get to hulu, or
any other ipv4 only eyeball service. You still need the ipv4s to operate a
proper network, and good luck figuring out which services are blacklisting
your new /24 because the ipv4 space used to be a VPN provider, and the "in"
thing to do for these services is to block VPNs.


There are many IPv6-only eyeball networks.  Definitely many examples in
wireless (T-Mobile, Sprint, BT ) and wireline (DT with DS-Lite in Germany,
Orange Poland ...) and even more where IPv4 NAT44 + IPv6 is used.  Just
saying, having ipv6 hedges a lot of risk associate with blacklisting and
translation related overhead and potentially scale and cost of IPv4
addresses.




On 11 June 2018 at 09:21, Ca By  wrote:


On Sun, Jun 10, 2018 at 8:43 AM Stan Ouchakov 
Hi,

Can anyone recommend transfer market brokers for ipv4 addresses? Need
clean /24 asap. ARIN's waiting list is too long...

Thanks!


-Stan

Meanwhile, FB reports that 75% of mobiles in the USA reach them via

ipv6

https://code.facebook.com/posts/635039943508824/how-ipv6-dep
loyment-is-growing-in-u-s-and-other-countries/


And Akaimai reports 80% of mobiles

https://blogs.akamai.com/2018/06/six-years-since-world-ipv6-
launch-entering-the-majority-phases.html


And they both report ipv6 is faster / better.

Re: Impacts of Encryption Everywhere (any solution?)

[Lee Howard]

On 05/28/2018 10:23 AM, Mike Hammett wrote:

Has anyone outside of tech media, Silicon Valley or academia (all places wildly 
out of touch with the real world) put much thought into the impacts of 
encryption everywhere?

See "Effects of Pervasive Encryption on Operators."
https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/?include_text=1

TLS1.3 uses ephemeral keys, so even if you own both endpoints and 
everything in the middle, you can't decrypt a flow without some 
yet-to-be-developed technology.

QUIC encrypts everything, and of course, HTTPS.




So often we hear about how we need the best modern encryption on all forms of 
communication because of whatever scary thing is trendy this week (Russia, NSA, 
Google, whatever). HTTPS your marketing information and generic education 
pieces because of the boogeyman!

However, I recently came across a thread where someone was exploring getting a 
one megabit connection into their village and sharing it among many. The crowd 
I referenced earlier also believes you can't Internet under 100 megabit/s per 
home.


Yeah. Too many people forget that most of the Internet is mobile, and 
mobile != LTE. People also assume packet loss < 0.1%, latency <100ms, 
and power reliability >99%.

However, this could be wildly improved with caching ala squid or something 
similar. The problem is that encrypted content is difficult to impossible for 
your average Joe to cache. The rewards for implementing caching are greatly 
mitigated and people like this must suffer a worse Internet experience because 
of some ideological high horse in a far-off land.

Some things certainly do need to be encrypted, but encrypting everything means 
people with limited Internet access get worse performance OR mechanisms have to 
be out in place to break ALL encryption, this compromising security and privacy 
when it's really needed.

To circle back to being somewhat on-topic, what mechanisms are available to 
maximize the amount of traffic someone in this situation could cache? The 
performance of third-world Internet depends on you.

A proxy is all I've thought of. But it means everything is dependent on 
the proxy, and it's even in-path for things that really should be 
encrypted, like email and messaging.
I can't imagine why the weather should be encrypted, when everyone in a 
location wants to know the forecast.


Lee

Re: IPv4 smaller than /24 leasing?

[Lee Howard]

ARIN's fee for a /24 is $250 https://www.arin.net/fees/fee_schedule.html

That's about 1/15th of the price of a /24 on the market.

Of course, they don't have any /24s.

Unless, of course, you're deploying IPv6 and just need the /24 for your 
NAT64 box, DS-Lite AFTR, or MAP-T BR. 
https://www.arin.net/policy/nrpm.html#four10


Lee

PS: Let me know if you're considering this; I'll help.


On 03/13/2018 01:19 PM, Justin Wilson wrote:

On the consulting side, I do smaller than /24 blocks to customers over tunnels. 
 So far this is the only option we have found that works for the smaller ISP. 
We all know the routing table is bloated. We all know everyone *should* be 
moving toward IPV6.  A whole different discussion.  But, for now you have a 
subset of operators that are big enough to do BGP, maybe join an exchange, but 
not big enough to afford buying v4 space for each of their customers.  So they 
are utilizing a full /24 just to utilize it.  Things such as doing 1:many nat 
at each tower, doing Carrier Grade nat, and other things make it where they 
don’t necessarily need an IP per customer.  We all know that is ideal, but it’s 
not practical for the small to medium ISP.   Folks have brought up the argument 
that buying IPS is just the cost of doing business these days.  I argue that it 
isn’t.  I see networks with 2000 users and only a /24 running along very happy.

I agree that the global routing table is pretty bloated as is.  But what kind 
of a solution for providers who need to participate in BGP but only need a /25? 
I can’t see going below that.


Justin Wilson
j...@mtin.net

www.mtin.net
www.midwest-ix.com


On Mar 13, 2018, at 10:56 AM, Naslund, Steve  wrote:


Yes, exactly right.  You would probably have to tunnel the /27 back to where the >/24 
lives.  That's the only way I can see of it working "anywhere".  That's a 
technically valid solution but maybe not so hot if you are looking for high 
redundancy/availability since you are dependent on the tunnel being up and working.

As always the reputation of the aggregate is going to be critical as to how well this 
works for you.  It seems to me that increasingly these "portable" blocks have 
murky histories as spam and malware sources.  I would rather have a block assigned by a 
reputable upstream provider than to do this.

Steven Naslund
Chicago IL


Le 2018-01-04 20:16, Job Snijders a écrit :

On Thu, 4 Jan 2018 at 20:13, Filip Hruska  wrote:


I have stumbled upon this site [1] which seems to offer /27 IPv4
leasing.
They also claim "All of our IPv4 address space can be used on any
network in any location."

I thought that the smallest prefix size one could get routed
globally is /24?


Yes

So how does this work?
Probably with GRE, IPIP or OpenVPN tunnels.

Kind regards,

Job

IPv4 /24 is commonly the minimal chunk advertised to (and accepted by)
neighbors. If I run a global (or regional) network, I may advertise this
/24 -- or rather an aggregate covering it -- over my diverse
interconnection with neighbors, your /27 being part of the chunk and
routed to you internally (if you're va customer)-- no need for
encapsulation efforts. Similar scenario may be multi-upstream, subject
to acceptance of "punching holes in aggregates"... Am I missing
something? What's the trigger for doing tunneling here?

Happy New Year '18, by the way !

mh

Re: cgnat - how do you handle customer issues

[Lee Howard]

On 02/27/2018 12:52 PM, Aaron Gould wrote:

Thanks

  


For #2 – what if the ports allocated aren’t enough for the amount of inet 
traffic the customer site uses ?  …is the customer denied service based on 
insufficient port range ?  …or are they assigned another block within that some 
ip’s range of I think it’s 0-64k or 1025-64k… but how far can you take that 
before there aren’t anymore port blocks left on that single ip ?  …and if you 
have to allocate that customer another port block from a *different* ip, then 
we are in the situation of the bank website not liking the fact that the 
session is bouncing to a different ip maybe ?



Yes, common problem, and the session just fails (TCY SYN dropped) 
because of insufficient ports.
Most CGNs allow you to configure a range of ports for a customer, and 
reserve an additional range if they need more ports. Yes, if you 
allocate 1000 ports for one IPv4 address to each of 50 customers and 
they all need hundreds more ports than that, you're going to run out of 
ports and connections fail.


This is why you have IPv6. Even while many web sites and apps don't 
support IPv4, enough do that it relieves some pressure on your CGN.


Lee
  


- Aaron

  


From: Michael Crapse [mailto:mich...@wi-fiber.io]
Sent: Tuesday, February 27, 2018 11:19 AM
To: Mike Hammett
Cc: Aaron Gould; NANOG list
Subject: Re: cgnat - how do you handle customer issues

  


For number 2, I'm a fan of what mike suggests. I believe the technical term is 
MAP-T.
For number 1, anyone who wants one, gets one. We provide free public static IP 
to any customer who asks for one. Another solution, using above solution is to 
ask them which ports they need, and forward those to them using a port within 
their assign range. i.e. teach them how to access their home web server using a 
different port(say 32424, or similar). This won't solve all the issues, which 
is why we use solution 1.

  


On 27 February 2018 at 09:32, Mike Hammett  wrote:

I'm a fan of nailing each customer IP to a particular range of ports on a given 
public IP. Real easy to track who did what and to prevent shifting IPs.




-
Mike Hammett
Intelligent Computing Solutions

Midwest Internet Exchange

The Brothers WISP

- Original Message -

From: "Aaron Gould" 
To: Nanog@nanog.org
Sent: Tuesday, February 27, 2018 10:30:21 AM
Subject: cgnat - how do you handle customer issues


Couple questions please. When you put thousands of customers behind a cgnat
boundary, how do you all handle customer complaints about the following.



1 - for external connectivity to the customers premise devices, not being
able to access web servers, web cameras, etc, in their premises?



2 - from the premise natted device, when customers go to a university or
bank web site, how do you handle randomly changing ip addresses/ports that
may occur due to idle time and session tear-down in nat table such that the
bank website has issues with seeing your session ip change?





-Aaron



  

Re: cgnat - how do you handle customer issues

[Lee Howard]

On 02/27/2018 11:30 AM, Aaron Gould wrote:

Couple questions please. When you put thousands of customers behind a cgnat
boundary, how do you all handle customer complaints about the following.

  


1 - for external connectivity to the customers premise devices, not being
able to access web servers, web cameras, etc, in their premises?

For web servers, you gently remind them of their ToS, and offer to 
upgrade them to a business account.


You offer to upgrade them to native IPv4, for a fee, and suggest they 
contact the manufacturer to see why it doesn't support IPv6.

I've heard of PCP for this, but never seen it in production on CPE.

I saw an early prototype of DS-Lite that included a customer portal that 
would allow the customer to enable port forwarding, but I can't imagine 
trying to walk a customer through two layers of port forwarding.


Most of these consumer electronics devices long ago started using 
ICE/TURN/STUN, and/or the company's web portal as their external 
communication platform. Doesn't mean all of them do.




2 - from the premise natted device, when customers go to a university or
bank web site, how do you handle randomly changing ip addresses/ports that
may occur due to idle time and session tear-down in nat table such that the
bank website has issues with seeing your session ip change?

  



You can extend your idle timers, of course, but only so much before 
you're squatting on all your ports.
After that, it's down to explaining to the university, bank, etc. that 
they need IPv6 if they want their web site to be reachable. Or at least 
they need to extend their idle timers.


Lee



  


-Aaron

IPv6 operations discussions

[Lee Howard]

The IETF v6ops working group is chartered to improve the operation of IPv6.
We have several active documents right now that would benefit from broader
operator feedback. For instance, there is current active discussion on:

Requirements for IPv6 Routers

This document provides a list of requirements for operators’ routers. Is
it clear and exhaustive?

Basic Requirements for IPv6 Customer Edge Routers

What transition technologies should all CPE vendors put in their devices?
The current version proposes all of: 464xlat, DS-Lite, lw4o6, MAP-E, MAP-T,
6in4, and 6rd, as well as IPv4 multicast over IPv6.
There are related documents that split out some requirements for further
discussion.

Happy Eyeballs Version 2: Better Connectivity Using Concurrency

Is this a useful update to the existing Happy Eyeballs specification
(rfc6555)? Should we update Happy Eyeballs?
  
Considerations For Using Unique Local Addresses

Are ULAs useful, or are they a natural and risky predecessor to IPv6 NAT?


It would help future IPv6 operations if current operators would read these
documents and comment on them on the mailing list:
https://www.ietf.org/mailman/listinfo/v6ops
Note Well that comments become part of the IETF record, and thank you for
them.


Lee
v6ops co-chair

Re: Leasing /22

[Lee Howard]

From:  Michael Crapse <mich...@wi-fiber.io>
Date:  Monday, January 22, 2018 at 5:27 PM
To:  Mark Andrews <ma...@isc.org>
Cc:  Lee Howard <l...@asgard.org>, NANOG list <nanog@nanog.org>
Subject:  Re: Leasing /22

> Customers on ps4s and xboxes will hate you. They will always get "strict" nat,
> and it's your fault not mega corporation X's fault for not releasing IPv4s

Maybe. You don’t have to configure strict NAT on your translator (DS-Lite’s
pretty good at this, and although I’m a few weeks away from testing consoles
through 464xlat and MAP, they should work, too). And their NAT workarounds
are pretty sophisticated now.

There comes a point when winning your customers’ love isn’t profitable. I
don’t know if that point is $16/address for you, or $30, or $40, or $90.
Maybe it varies, depending on the customer.

That’s why I suggested in “TCO of CGN”[1] that everyone figure out for
themselves how much money you might lose to unhappy customers via CGN, and
compare it to how much addresses cost, and at what price point you might
turn around and sell addresses. My findings then, based on assumptions that
almost certainly are not true for any particular network, and which may have
changed, suggest that buying addresses still makes sense.


Lee

[1] http://ipv6.nanog.org/meetings/abstract?id=2025


> 
> On 22 January 2018 at 15:23, Mark Andrews <ma...@isc.org> wrote:
>> Add to that CGN from RFC 6598 addresses (100.64/10) + IPv6 though that
>> reaches its limit at ~4M customers.
>> 
>> Native IPv4 with a GUA to customers is essentially unavailable for new
>> ISPs.  It’s a matter of picking which flavour of NAT you and your
>> customers are going to use.  The sooner ALL ISP’s provide IPv6 to their
>> customers the sooner we restore delivering the Internet to the customers.
>> 
>> Mark
>> 
>>> > On 23 Jan 2018, at 9:05 am, Lee Howard <l...@asgard.org> wrote:
>>> >
>>> > IPv6 still solves your problem if you add any of NAT64, DS-Lite, 464xlat,
>>> > MAP-T, MAP-E.
>>> >
>>> > Yes, you’re NATing, but only the traffic to places like Hulu, and it will
>>> > decrease over time. And while you need addresses for the outside of the
>>> > translator, you don’t need as many (or to get more as frequently).
>>> >
>>> > Lee
>>> >
>>> > On 1/20/18, 10:20 AM, "NANOG on behalf of Mike Hammett"
>>> > <nanog-boun...@nanog.org on behalf of na...@ics-il.net> wrote:
>>> >
>>>> >> It's not really scraping the bottom of the barrel if your customers are
>>>> >> using Hulu and they're complaining because Hulu isn't responsive to
>>>> >> fixing their problems (geo-location, v6, etc.).
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> -
>>>> >> Mike Hammett
>>>> >> Intelligent Computing Solutions
>>>> >> http://www.ics-il.com
>>>> >>
>>>> >> Midwest-IX
>>>> >> http://www.midwest-ix.com
>>>> >>
>>>> >> - Original Message -
>>>> >>
>>>> >> From: "Ca By" <cb.li...@gmail.com>
>>>> >> To: "Michael Crapse" <mich...@wi-fiber.io>
>>>> >> Cc: "NANOG list" <nanog@nanog.org>
>>>> >> Sent: Friday, January 19, 2018 9:54:23 PM
>>>> >> Subject: Re: Leasing /22
>>>> >>
>>>> >> On Fri, Jan 19, 2018 at 5:48 PM Michael Crapse <mich...@wi-fiber.io>
>>>> >> wrote:
>>>> >>
>>>>> >>> Has Hulu, or a thousand other content distributors considered IPv6?
>>>>> >>> Because
>>>>> >>> you can't even tunnel to ipv4 without setting off VPN alarms with
>>>>> HULU.
>>>>> >>>
>>>> >>
>>>> >> Hulu? Really scraping the bottom of the barrel of content providers that
>>>> >> dont use ipv6 these days.
>>>> >>
>>>> >> Netflix and Youtube support v6 ... and thousand of others (thousands
>>>> just
>>>> >> on Cloudflare where v6 is default on)
>>>> >>
>>>> >> About 80% of my traffic is native e2e v6, mostly google / youtube / fb /
>>>> >> netflix / apple / amazon — but your mix may vary.
>>>> >>
>>>> >>
>>>> >>
>>>>> >>>
>>>>> >>>
>>>>> >>> On 19 January 2018 at 18:38, Andrew Kirch <trel...@trelane.net> wrote:
>>>>> >>>
>>>>>> >>>> On Fri, Jan 19, 2018 at 4:59 PM Ryan Gard <ryang...@gmail.com>
>>>>>> wrote:
>>>>>> >>>>
>>>>>>> >>>>> We're on the hunt yet again for an additional /22 to lease, and
are
>>>>>>> >>>>> wondering what the best options are out there?
>>>>>>> >>>>>
>>>>>>> >>>>> Our usual suspects that we've reached out to in the past seem to
be
>>>>> >>> plum
>>>>>>> >>>>> out... Any recommendations?
>>>>>>> >>>>>
>>>>>>> >>>>> Thanks!
>>>>>>> >>>>>
>>>>>>> >>>>> --
>>>>>>> >>>>> Ryan Gard
>>>>>>> >>>>>
>>>>>> >>>> Have you considered IPv6?
>>>>>> >>>>
>>>>> >>>
>>>> >>
>>>> >>
>>> >
>>> >
>> 
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742 <tel:%2B61%202%209871%204742>   INTERNET:
>> ma...@isc.org
>> 
> 

Re: Leasing /22

[Lee Howard]

IPv6 still solves your problem if you add any of NAT64, DS-Lite, 464xlat,
MAP-T, MAP-E. 

Yes, you’re NATing, but only the traffic to places like Hulu, and it will
decrease over time. And while you need addresses for the outside of the
translator, you don’t need as many (or to get more as frequently).

Lee

On 1/20/18, 10:20 AM, "NANOG on behalf of Mike Hammett"
 wrote:

>It's not really scraping the bottom of the barrel if your customers are
>using Hulu and they're complaining because Hulu isn't responsive to
>fixing their problems (geo-location, v6, etc.).
>
>
>
>
>- 
>Mike Hammett 
>Intelligent Computing Solutions
>http://www.ics-il.com
>
>Midwest-IX 
>http://www.midwest-ix.com
>
>- Original Message -
>
>From: "Ca By" 
>To: "Michael Crapse" 
>Cc: "NANOG list" 
>Sent: Friday, January 19, 2018 9:54:23 PM
>Subject: Re: Leasing /22
>
>On Fri, Jan 19, 2018 at 5:48 PM Michael Crapse 
>wrote: 
>
>> Has Hulu, or a thousand other content distributors considered IPv6?
>>Because 
>> you can't even tunnel to ipv4 without setting off VPN alarms with HULU.
>> 
>
>Hulu? Really scraping the bottom of the barrel of content providers that
>dont use ipv6 these days.
>
>Netflix and Youtube support v6 ... and thousand of others (thousands just
>on Cloudflare where v6 is default on)
>
>About 80% of my traffic is native e2e v6, mostly google / youtube / fb /
>netflix / apple / amazon — but your mix may vary.
>
>
>
>> 
>> 
>> On 19 January 2018 at 18:38, Andrew Kirch  wrote:
>> 
>> > On Fri, Jan 19, 2018 at 4:59 PM Ryan Gard  wrote:
>> > 
>> > > We're on the hunt yet again for an additional /22 to lease, and are
>> > > wondering what the best options are out there?
>> > > 
>> > > Our usual suspects that we've reached out to in the past seem to be
>> plum 
>> > > out... Any recommendations?
>> > > 
>> > > Thanks! 
>> > > 
>> > > -- 
>> > > Ryan Gard 
>> > > 
>> > Have you considered IPv6?
>> > 
>> 
>
>

Re: Waste will kill ipv6 too

[Lee Howard]

From:  <christopher.mor...@gmail.com> on behalf of Christopher Morrow
<morrowc.li...@gmail.com>
Date:  Wednesday, December 20, 2017 at 6:07 PM
To:  Lee Howard <l...@asgard.org>
Cc:  Mike <mike-na...@tiedyenetworks.com>, nanog list <nanog@nanog.org>
Subject:  Re: Waste will kill ipv6 too

> 
> 
> On Wed, Dec 20, 2017 at 2:16 PM, Lee Howard <l...@asgard.org> wrote:
>> 
>> I’ve tried several times to come up with a scenario that leads to
>> depletion in less than 200 years, and I haven’t managed it. Can you do it?
> 
> during some ARIN discussions that revolved around Transition Technologies and
> allocations to large ISPs, there were more than a few folk batting around the
> idea that they may need to allocate a /24 or a /20 even to a single provider.
> 
> I believe DT has a /19 assigned to them currently? how many /19's are there in
> the v6 space? (524288-ish)
> That's only ~100x the current number of active ASN in the field. It's unclear
> (to me) how many of those could/would justify a /19 equivalent, and how fast
> the ASN field is growing over time.

DT is one of the largest ISPs in the world, isn’t it?

Can you devise a scenario in which there are 524,288 ISPs the size of DT?
Or one where every currently active ASN, times 100X, needs/justifies a /19?

> 
> 200 years seems optomistic, 20 years seems easy to imagine surpassing though.
> What's the sweet spot?
>  

200 years seems pessimistic to me. Every scenario I run uses ridiculously
profligate assumptions, and usually multiplies those by a few orders of
magnitude. Even extrapolating from your math above, I don’t get less than
CE.

Lee

Re: Waste will kill ipv6 too

[Lee Howard]

On 12/20/17, 1:23 PM, "NANOG on behalf of Mike"  wrote:

>On 12/17/2017 08:31 PM, Eric Kuhnke wrote:
>> some fun examples of the size of ipv6:
>>
>> https://samsclass.info/ipv6/exhaustion-2016.htm
>>
>> 
>>https://www.reddit.com/r/theydidthemath/comments/2qxgxw/self_just_how_big
>>_is_ipv6/
>>
>
>
>Every time I see these "Look how many more addresses we have now with
>IPv6", I just shake my head.
>
>  Yes, the address space is very large. But, all of the protocols, all
>of the addressing guides, all of the operational 'best practices', ALL
>OF IT, increases by orders of magnitude the amount of waste along with
>it. Call this the 'shavings', in IPv4 for example, when you assign a P2P
>link with a /30, you are using 2 and wasting 2 addresses. But in IPv6,
>due to ping-pong and just so many technical manuals and other advices,
>you are told to "just use a /64' for your point to points. So, the
>actual waste is dilutes the actual implementable size of the total ipv6
>address space due to the waste component. And I have not yet seen any
>study or even proposed theory to explore what the IPv6 Internet would
>look like, if used in place of all IPv4 in all the places and ways that

Okay, so do the thought experiment.

Let’s say 10 billion people in the world.
Let’s say each of them has 10 devices, each with a /64, and to be
ridiculous, each with a p2p link to the others, so we have 100 /64 per
person.
That’s 1 trillion /64s.
Oh, dear, I’ve used up the first /27 of IPv6 space.

What if we try giving ten /48s to each of 10 billion people, one for each
of the ten providers they’ll have? Sure, I’m handwaving the p2p links, but
that’s why we assign that /48.
That’s 100 billion /48s, which is something like a /11.

I’ve tried several times to come up with a scenario that leads to
depletion in less than 200 years, and I haven’t managed it. Can you do it?

> why is
>nobody thinking or talking about the looming exhaustion of ieee OUI
>addresses?



> Network cards made 15 years ago and since consigned to the
>electronics scrap heap in the sky, take with them their addresses never
>to be reused again (unless you are a freak like me and keep some for
>'positively never assigned anywhere'). And old dead companies that were
>assigned OUIs, they get 24 bits of address space to take to their
>graves. We should be re-thinking mac addressing altogether too.

Like EUI-64?  https://standards.ieee.org/develop/regauth/tut/eui.pdf

Lee

Re: Companies using public IP space owned by others for internal routing

[Lee Howard]

On 12/19/17, 8:50 PM, "NANOG on behalf of Owen DeLong"
 wrote:

>
>> On Dec 19, 2017, at 07:39 , Livingood, Jason
>> wrote:
>> 
>> On 12/18/17, 2:36 PM, "NANOG on behalf of Harald Koch"
>> wrote:
>>> They could use IPv6. I mean, if the mobile phone companies can figure
>>>it out, surely an ISP can...
>> 
>> Except for cases when it is impossible or impractical to update
>>software on a great number of legacy devices…
>> 
>> JL
>> 
>> 
>Yeah, in those cases, they should use IPv6 + NAT64 or similar mechanism.

I’m a fan of IPv6-only plus translation, but not in this case.
If I have a functioning management network that’s mostly in IPv6 and
partly in rfc1918 space (or even squatted space), I don’t get much out of
NAT64. Renumbering the servers that actually touch/manage devices gets,
what, a /29 of IPv4 addresses? Better to focus on evolving to whatever
will replace those legacy devices.

Lee 

>
>Owen
>
>

Re: Companies using public IP space owned by others for internal routing

[Lee Howard]

On 12/19/17, 11:52 PM, "NANOG on behalf of Mark Andrews"
 wrote:

>
>> On 20 Dec 2017, at 2:39 am, Livingood, Jason
>> wrote:
>> 
>> On 12/18/17, 2:36 PM, "NANOG on behalf of Harald Koch"
>> wrote:
>>> They could use IPv6. I mean, if the mobile phone companies can figure
>>>it out, surely an ISP can...
>> 
>> Except for cases when it is impossible or impractical to update
>>software on a great number of legacy devices…
>> 
>> JL
>
>You mean devices where the manufacture ignore IPv6 and shipped you a dud.
> Even devices with a 15 year life cycle should be IPv6 capable today.

“should” doesn’t buy developer cycles, especially for EOL products or from
bankrupt vendors.

You deal with the network you have, upgrade what you can, and replace the
rest as fast as you can while doing what it takes to stay in business.

Lee

Re: F Y I

[Lee Howard]

 


On 10/17/17, 5:33 PM, "NANOG on behalf of Christopher Morrow"
 wrote:

>you know, the Sci-Hub folk could fix this themselves... with some
>authentication requirements... and probably by just unplugging from the
>intertubes?

"Sci-Hub’s founder, has previously told The Scientist the site plans to
ignore the lawsuit.” How would Sci-Hub consider this a “fix”?

What enforcement mechanism would the Court have against Sci-Hub?

The idea of making third parties (ISPs) incur costs (updating ACLs or
poisoning DNS) to enforce the order is pretty bad, and doesn’t stop Tor
access. Sorry I didn’t have a chance to file an amicus before the ruling
tomorrow.



Lee


>
>On Tue, Oct 17, 2017 at 5:04 PM, Robert Mathews (OSIA)
>
>wrote:
>
>>
>> Judge Recommends Ruling to Block Internet Access to Sci-Hub
>> The American Chemical Society seeks a broad order that includes millions
>> of dollars in damages and demands action from Internet service providers
>> and search engines.
>> By Diana Kwon | October 4, 2017
>>
>> http://www.the-scientist.com/?articles.view/articleNo/50563/
>> title/Judge-Recommends-Ruling-to-Block-Internet-Access-to-Sci-Hub/
>> http://www.the-scientist.com/?articles.view/articleNo/50361/
>> title/Publishers--Legal-Action-Advances-Against-Sci-Hub/
>>
>

Re: 4 or smaller digit ASNs

[Lee Howard]

> On Oct 12, 2017, at 1:01 AM, James Breeden  wrote:
> 
> Hello NANOG...
> 
> I have a client interested in picking up a new AS number but they really want 
> it to be 3 or 4 digits in length.
> 
> Is there a process to request this from ARIN, or doss anyone know of unused 
> ASns fitting this that anyone is looking to sell for some quick cash?
> 

It's part of the ARIN transfer process, 
https://www.arin.net/policy/nrpm.html#eight specific 8.3, "IPv4 numbers 
resources and ASNs may be transferred according to the following conditions."

ARIN has a Specified Transfer Listing Service, 
https://www.arin.net/resources/transfer_listing/index.html so you could check 
there.
I didn't see any ASNs listed, so you may need to call a broker, such as one 
listed under 
https://www.arin.net/resources/transfer_listing/facilitator_list.html

A list of ASNs that have been transferred policy can be found at 
https://www.arin.net/public/transferLog.xhtml#NRPM-8.3ASNs



> Thanks!
> James
> 

Hope that helps,

Lee

> 
> 
> 
> Sent via the Samsung Galaxy S7 active, an AT 4G LTE smartphone

Re: DHCPv6-PD -> Lack of route injection in RFC

[Lee Howard]

On 9/23/17, 1:51 AM, "nanog-boun...@nanog.org on behalf of
valdis.kletni...@vt.edu"  wrote:

>On Sat, 23 Sep 2017 08:47:32 +1000, Mark Andrews said:
>> You know CPE devices are routers.  They can tell you what routes
>> DHCP has given them.  That annoucement could be cryptographically
>> authenticated.
>
>This is, of course, a lot easier if the CPE already has onboard the needed
>software to do that, or you have the ability to push it out.

Right. How many residential market gateways support any routing protocol
at all? How many support RIPv2? How many support RIPng. Being routers does
not mean they support any dynamic routing protocol. If I were an ISP, I
would be very skeptical of the return on adding routing support to every
gateway I supported, plus an RPKI.

>
>Is anybody from Comcast or other eyeball network willing to say (even
>roughly)
>what percent of CPE is gear they supply, versus gear that people get at
>Best
>Buy or Walmart and just plug in, versus (if they can identify it) gear
>that's
>been reflashed by clued customers?

It varies 0-100% based on network, year, and the mood of whoever makes the
decision about how to handle CPE. Some ISPs provide a gateway to all of
their customers, and some of those customers then put them into bridged
mode. (I think Vz FiOS, for instance, always comes with a gateway). Some
provide a gateway for free, which may be worth much more or less than you
paid for it, depending on the philosophy of the ISP. Some assume you want
a gateway and charge you several dollars a month for it.

Lee

Re: IPv6 migration steps for mid-scale isp

[Lee Howard]

On 9/23/17, 7:14 AM, "NANOG on behalf of Fredrik Sallinen"
 wrote:

>Please correct me If I'm wrong, AFAIK 464XLAT works best with mobile
>networks and its not suitable for fixed broadband. right?

Should work fine in landline networks, but (as Jordi says) it’s hard to
find support in retail CPE your customers are likely to own. Same is true
for MAP-T and MAP-E.

If anyone knows of retail CPE supporting any of those, or if you’re a
gateway vendor selling those, let me know, I’m interested.

Lee

>
>On Mon, Sep 18, 2017 at 10:28 PM, JORDI PALET MARTINEZ
> wrote:
>> Fully agree, 464XLAT is the way to go.
>>
>> We have tested this in many IPv6-only access deployments, non-cellular
>>networks (cellular is well tested by T-Mobile and others, that have got
>>it in production for years).
>>
>> We always have the issue of the CPEs support, but this is the same
>>problem if you want to go to lw4o6, MAP, etc. In general, newer
>>transition mechanisms, aren’t well supported.
>>
>> So, you either use OpenWRT if you can re-flash the CPEs, or you push
>>your vendors to make sure they provide a firmware upgrade.
>>
>> This is the reason I started to work on an update of the RFC7084
>>(https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/ and
>>https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc7084-bis-transition
>>/) and see also the related discussion in v6ops.
>>
>> Also, I run a panel with CPE vendors in the last week APNIC meeting,
>>and the interesting thing is that they confirmed there is no any
>>technical issue to support those (hardware is ok), and they have already
>>developed it, just waiting for customers to ask for it.
>>
>> 
>>https://conference.apnic.net/44/program/schedule/#/day/6/bof-discussion-w
>>ith-ipv6-ce-vendors
>>
>> I will compile a report out of this panel ASAP.
>>
>> So please, keep pushing your vendors for it!
>>
>> Regards,
>> Jordi
>>
>>
>> -Mensaje original-
>> De: NANOG  en nombre de Brock Tice
>>
>> Responder a: 
>> Fecha: viernes, 15 de septiembre de 2017, 17:14
>> Para: Fredrik Sallinen 
>> CC: 
>> Asunto: Re: IPv6 migration steps for mid-scale isp
>>
>> We are small but we are just about out of IPv4 and aren't going to
>>get
>> or buy any more. We have been testing for a while.
>>
>> > Shall I go for IPv6-only deployment or dual stack?
>>
>> You should plan for adding customers eventually that are IPv6-only,
>> unless you have all the v4 you will ever need, and you will need to
>> reserve IPv4 address blocks for translation.
>>
>> > How to identify address CPE and legacy application issues?
>>
>> Legacy application issues can be solved (for the most part) with
>> 464XLAT, which also solves IP-literal-in-HTML problems. You need
>>PLAT at
>> the core and CLAT at the client. Unfortunately so far the only good
>>way
>> we've found to do CLAT is OpenWRT on the CPE or router. We are
>>getting
>> ready to bundle Linksys routers flashed with OpenWRT.
>>
>> For PLAT at the core we are running jool. It's actually quite
>>simple to
>> set up and we are currently using OSPF to do anycast, but we will
>> probably be migrating to a single set of HA servers in the core. The
>> good news is that even if it goes down, Netflix and Facebook will
>>still
>> work as they are fully functional on v6.
>>
>> We have tested this in my home and at my office with IPv6-only
>> VLANs/wireless SSIDs, mostly without a hitch.
>>
>> If you run this setup without the CLAT on the client side you get
>>NAT64
>> so it still will work for most things.
>>
>> I would be very, very happy if larger ISPs would put pressure on
>>router
>> manufacturers to support CLAT, we have no clout. I would also love
>>to
>> hear if any of this is stupid or if there's a better way.
>>
>> --Brock
>>
>>
>>
>>
>> **
>> 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
>>confidential. The information is intended to be for the exclusive use of
>>the individual(s) named above and further non-explicilty authorized
>>disclosure, copying, distribution or use of the contents of this
>>information, even if partially, including attached files, is strictly
>>prohibited and will be considered a criminal offense. If you are not the
>>intended recipient be aware that any disclosure, copying, distribution
>>or use of the contents of this information, even if partially, including
>>attached files, is strictly prohibited, will be considered a criminal
>>offense, so you must reply to the original sender to inform about this
>>communication and delete it.
>>
>>
>>
>

Re: DHCPv6-PD -> Lack of route injection in RFC

[Lee Howard]

On 9/22/17, 3:12 AM, "NANOG on behalf of Steve Teusch"
 wrote:

>I am running into venders that do not support injection of a delegated
>route when operating as a DHCPv6 relay (or server for that matter).
>Brocade supports this, but I am not finding this as part of any of the
>RFC's.  This is to deliver home ISP service, so it is very important or
>return packets won't go to the client unless the route is manually added
>as a routing protocol is not an option.  There should be a MUST activity
>for this somewhere.
>
>Anyone know what gives?


Well, it’s weird for a DHCPv6 relay process to inspect relayed Reply
messages and use them to update the routing table. Weird, but I’ve done it.
What origin type do you use for that route?  Static, really?

This behavior was requested by operators who needed it; I don’t remember
whether we even went to the IETF with it. I think descriptions exist in
CableLabs IPv6 docs; maybe in BBF docs, too.

Any vendor who doesn’t do it is in the process of shutting down their ISP
access router business.

Lee

Re: IPv6 migration steps for mid-scale isp

[Lee Howard]

On 9/13/17, 8:08 AM, "NANOG on behalf of Fredrik Sallinen"
 wrote:

>Hello,
>
>Recently we have decided to start IPv6 migration in our network. We
>have ~1K BNGs and connecting our customers to network using PPPoE.
>I'd be interested in hearing from the technical community about their
>experiences and recommendations on this process. I'm wondering:
>
>Shall I go for IPv6-only deployment or dual stack?

Dual-stack is the best way to get to IPv6-only. You’ll need IPv6-only in
order to solve the IPv4 runout problem, though “only” is likely to include
translation.

>Where to start with IPv6? (core, edge or ...)

Web site.
Then core and peering.
Then push toward regional networks. You’ll need IPv6 into at least the
part of your data center does provisioning and monitoring.
Then start pushing to customers.

>What are the best practices for ISPs?

Lots of documents exist. Here’s one: https://tools.ietf.org/html/rfc6782


>What are the costs and return on investment?

Oh, I have so much to say on this topic. Search for “TCO of CGN” and “TCO
of IPv6” to find it.
You should have very little incremental capital cost; that is, you
shouldn’t have to buy new hardware, because practically anything less than
ten years old can support IPv6. Whether it *does* is a question.
You’ll have some opex network engineering costs in testing and deployment,
which might be high(ish) if you have a lot of different equipment in your
network. Your biggest cost is likely to be the development labor to update
your IPAM, provisioning systems, management, logging, and tech support
tools to be able to store and use the new address format. Development is
likely to be what takes longest, so that’s really the place to start.

The return on investment is that you don’t have to spend $15 to buy an
IPv4 address for every new user you have to sign up. Or $25 per address in
2019, if trends continue. [1]
Depending on how happy you are with your transition mechanism (NAT64,
464xlat, MAP, etc.) you could, instead, sell off those IPv4 addresses.
“Hey, boss, we’ll turn up 10,000 new customers in 2019, right? We can
either spend $250,000 to buy addresses, or we can put 10% of our customers
behind NAT64 (or whatever) and sell their IPv4 addresses for $25 each.”
(Dozens of NANOGers laugh, a few cock their heads and think “maybe…”).

>How to identify address CPE and legacy application issues?

How do you do it now?
I’m guessing you test CPE that you provide, at least for basic
functionality. 
Some bugs still get past you. A few customers call, you notice a trend
among customers with X CPE that they have a problem in the area where you
just rolled out IPv6. You roll back IPv6 in that area or (hopefully) just
from those devices, and put that CPE in the lab and test the heck out of
it.

For legacy applications, it depends on the application. If you can update
it, that’s the best answer. Or you can put a NAT64 box in front of it (on
a VM, router, firewall, or load balancer—you don’t necessarily need new
hardware). But there’s also the entire rest of the old Internet: you will
probably want to have some kind of transition mechanism in place.

I know folks who specialize in transition mechanisms; I’ll follow up
privately so this doesn’t look like a sales pitch on the list.


>
>Fredrik
>

Lee


[1] Charts, using IPv4auctions.com (Hilco Streambank) data:
http://www.wleecoyote.com/blog/2017prices.htm

Re: IPv6 Loopback/Point-to-Point address allocation

[Lee Howard]

On 9/9/17, 12:06 PM, "NANOG on behalf of Kody Vicknair"
 wrote:

>All,
>
>I’ve been doing some reading in preparation of IPv6 deployment and
>figuring out how we will break up our /32. I think I’m on the right track
>in thinking that each customer will be allocated a /48 to do whatever
>they wish with it.

Yes.

>
>I’ve read recent BCOP drafts that have been approved by the IETF:
>https://www.ripe.net/publications/docs/ripe-554

BCOP isn’t an IETF BCP. But that’s a really minor detail; BCOPs much
better operator input than most IETF activities (IMHO, as an active IETF
participant).

>It looks like the smallest subnet that should ever be assigned is a /64
>on a particular link.
>
>
>Some questions that come to mind with IPv6:
>
>In regards to Point to point links my thinking is this:
>Assign a unique /64 to each point to point link with these addresses
>being Globally routable. This seems to be what our IX providers do when
>assigning us an IPv6 address. Am I correct in this train of thought?
>Why/Why not?

Yes, the general guidance is to reserve a /64 for the link and configure a
very small subnet (like /127) on the interfaces, to avoid a ping-pong
attack.

>
>In regards to core loopback addressing my initial thoughts are as follows:
>Assign a single /64 encompassing all /128’s planned for loopback
>addressing schemes. Should I be using Unique Local addressing for
>loopbacks instead of going with a Globally routeable addressing scheme?
>Should each interface IP configuration have a /64 or a /128?

You can use ULAs for this; I know of a moderately sized network that does.
I think most people still use GUA. You’re not wrong either way, though I
know some people get emotional about ULA.

>
>Also when talking about CPE mgmt addresses what do you think is a
>practical way of going about assigning “Private” addressing schemes for
>cpe management purposes.

Reserve another block from your /32 and route it separately.
As somebody else said, if you find you’re running out of address space in
IPv6, there’s no shame in requesting more than a /32.

>
>I’m sure some of these questions will be answered when I dive deeper into
>how OSPFv6 works as well as BGP in regards to IPv6.

Maybe, but don’t panic. It’s not significantly harder in IPv6 than in
IPv4. 

>
>Are any of you currently running IPv6 and wished you had done something
>differently during the planning phase that may have prevented headaches
>down the road?

I always tell people: you’re going to rewrite your address plan three
times. Do what you can with it, then start deploying through the network.
You’ll see what changes you need to make once you know how your network is
unique.

I wish I’d pushed harder for /48s for customers from the beginning, even
though we would’ve needed more address space. I wish I’d started sooner,
but more than that I wish my vendors had started sooner, especially CPE
vendors.

I wish I had just replaced broken equipment rather than working around it.

I wish I had had better monitoring of both IPv4 and IPv6 specific systems,
so I could tell when one address family failed.

I wish I had been able to plan my transition technology earlier, so I
could move from dual-stack to IPv6.


Lee



>
>
>
>
>Kody Vicknair
>Network Engineer
>
>
>[cid:imagebf3343.JPG@c9d2fbd2.4db10e0d] 
>
>Tel:985.536.1214
>Fax:985.536.0300
>Email:  kvickn...@reservetele.com
>Web:www.rtconline.com
>
>Reserve Telecommunications
>100 RTC Dr
>Reserve, LA 70084
>
>
>
>
>
>Disclaimer:
>The information transmitted, including attachments, is intended only for
>the person(s) or entity to which it is addressed and may contain
>confidential and/or privileged material which should not disseminate,
>distribute or be copied. Please notify Kody Vicknair immediately by
>e-mail if you have received this e-mail by mistake and delete this e-mail
>from your system. E-mail transmission cannot be guaranteed to be secure
>or error-free as information could be intercepted, corrupted, lost,
>destroyed, arrive late or incomplete, or contain viruses. Kody Vicknair
>therefore does not accept liability for any errors or omissions in the
>contents of this message, which arise as a result of e-mail transmission.
>

Re: ISP billing - data collection, correlation, and billing

[Lee Howard]

On 7/14/17, 2:47 PM, "NANOG on behalf of Luke Guillory"
 wrote:

>On the HFC / CMTS side of things we have IPDR which I believe has some
>open source collectors out there. I'm not sure that IPDR is used much
>outside of the HFC world though.

IPDR was my first thought as an alternative to SNMP. Is its accuracy
comparable? It’s been included into TR-069, so it’s theoretically
available to telcos, too. And usage-based billing is part of it’s purpose.


Not sure I’d want to use NetFlow/IPFIX, since by nature it tracks flows,
not bits, and I don’t want to record flows. But I’d be interested in
hearing others’ experience.


Lee

Re: Some advice on IPv6 planning and ARIN request, please

[Lee Howard]

On 7/7/17, 1:07 PM, "NANOG on behalf of Oliver O'Boyle"
 wrote:

> We're currently in the planning stage and can make
>whatever changes we need to.

I always say to just expect you’ll change your address plan three times.
Some people say, “I’ve only changed the address plan twice. . . so far.”

>
>Situation:
>
>We're an end-user org and qualify for a /40 assignment because we operate
>over 60 sites and some of those are/will be multihomed. We manage hotels
>in
>Canada only, but from coast to coast to coast and everywhere in between.
>Our corporate network and org structure is optimized for three regions. We
>also have, and continue to grow into, cloud infrastructure and foresee
>wanting to bring our own addresses (.e.g., to AWS VPC when that option
>becomes available). As such, an obvious design strategy would be to break
>the /40 into 4 x /42's. However, due to an imbalance in national site
>distribution, 50% of our sites are located in one region (Region A).
>Additionally, historical and forecasted growth indicates that it's
>perfectly reasonable for us to expect growth of an additional 16 sites in
>that same region over the next 3-5 years.

Even assuming, as you said: a /48 per hotel, it sounds like you’re
planning for:
Region A, 45 sites, minimum /42
Region B, <20 sites, minimum /44
Region C, <20 sites, minimum /44
Cloud stuff, minimum /48, but that might need more

However, as others have suggested, you might want to start from the
bottom, deciding the allocations within each hotel. It may be that you
need multiple /48s for HotelGuest, HotelLobby, HotelConference, and
HotelStaff SSIDs. 
A /64 per WiFi AP is an aboslute minimum, but a prefix per room (or guest)
would be better, and there are reasons to consider /56 and /48 per “end
user” in the hotel. Even if you can’t assign it with current WiFi
technology, your address plan should allow for an evolution to a better
way of doing things.
If my math works right, and you have between 127 and 255 rooms in a hotel:
255 * /56 = /48 just for HotelGuest. You may need a /44 per hotel, if
there are four separate networks.
Or:
255 * /48 = /40 just for HotelGuest. You may need a /36 per hotel.

As others have said, I’m assuming you treat guests to whom you provide
Internet service as customers.


>
>I think the ideal situation is out as ARIN policy wouldn't allow them to
>assign us a /36 at this time. Unless someone knows something that can help
>us here.

Try calling ARIN. Ask a hostmaster whether the End User or ISP category
makes more sense in your case. It’s also possible they’ll say “slow start”
and give you a /40 for your first hotel, and tell you to return in a week
when you need more.

But also, take into account [NRPM 6.5.8.2] "Requests forlarger
initial assignments, reasonably justified with supporting
documentation, will be evaluated based on the number of sites in an
organization’s network and the number of subnets needed to support any
   extra-large sites defined below.” There’s a lot of room within
policy to do sensible things with IPv6.

>
>Assuming we can't get a /36, my feeling is that less ideal situation #2 is
>better than #3 is better than #1 is better than #4, assuming we're
>following the following design best-practices:
>
>a) assign top-level aggregations evenly (which we'd be breaking a bit with
>option #2)
>b) reduce global routes as much as possible
>c) stay on the nibble boundary as much as possible
>d) default to /48 per site

Yes, all good goals. But none is critical to the success of your network
(except c, only if you plan to delegate reverse DNS). “As much as
possible” also implies “and no more than is possible.”

>
>Thanks in advance,
>Oliver


btw, I can’t wait to stay in your hotels once they have IPv6! I hope
you’ll be able to tweet or post here when it’s deployed, so we can
congratulate you, and maybe get some conferences to consider you as a
venue.

Lee

Re: IPv6 traffic percentages?

[Lee Howard]

On 6/22/17, 3:00 AM, "NANOG on behalf of Radu-Adrian Feurdean"

wrote:

>On Thu, Jun 22, 2017, at 08:18, Mukom Akong T. wrote:
>> 
>> On 18 June 2017 at 17:36, Radu-Adrian Feurdean > adrian.feurdean.net> wrote:>> so for the record, business customers are
>>much more active in
>>>  *rejecting* IPv6, either explictely (they say they want it
>>>  disabled) or>>  implicitly (they install their own router, not
>>>configured for
>>>  IPv6). The>>  bigger the business, the bigger the chance of rejection.
>> 
>> 
>> Did they per chance state their reasons for rejecting it?
>
>Not explicitly. But when we get something like "turn off that IPv6 crap
>!" we take it for: - they don't have a clearly defined need for it
> - they don't know how to deal with it
> - they don't want to deal with things they don't need (see the
>   irst point)... usually all of them at the same time.

That is my experience, too. When I was in IT, my response was to block
IPv6 at the firewall (until I learned my firewall was incapable of
examining IPv6 packets and therefore allowed ALL IPv6; I wasn’t allowed to
change firewalls so I used a router ACL to block it while I reviewed our
IPv6 security policy and looked for another job). When I was at an ISP, we
could route IPv6 to the customer, but until they enabled it, no traffic
would follow.

>
>To make it short : education. And we as as small ISP we have neither the
>resources, nor the motivation (because $$$ on the issue is negative) to
>do it (the education).

I think you’re talking about business education, not technical IPv6
education, right?
I recently posted my suggested technical reading list:
http://www.wleecoyote.com/blog/IPv6reading.html

But I think you’re asking for a business education series that goes:
1. Enterprise business consideration of IPv6
   a. It’s already on your network. All computers, tablets and phones have
at least Link Local, and some set up tunnels. Plus, if your employees have
dual-stack at home but single—stack VPN, you may not like your split
tunnel.
   b. Lower latency.
   c. Using IPv6 in interesting ways, like Segment Routing, Terastream bit
masking, IPv6 address as process ID.
   d. IPv4 runout doesn’t matter much to most enterprises. They only need
a couple of addresses for new branch offices. Those enterprises who have
their own IPv4 address block (from RIR, not ISP/LIR) should consider how
much they could sell it for. At $15/address, a /16 approaches US$1
million, which is real money to most CTOs.
http://www.wleecoyote.com/blog/2017prices.htm

2. Enterprise IPv6 implementation guidance
  a. https://tools.ietf.org/html/rfc7381  “Enterprise IPv6 Deployment
Guidelines” 
  b. Cost to Renumber and Sell IPv4
http://retevia.net/Downloads/EnterpriseRenumbering.pdf


I’ll see if I can write up #1 into a single paper or blog post in the next
few days. Anything else I should add?

Lee

>

Re: Nat

[Lee Howard]

On 1/7/16, 7:39 PM, "NANOG on behalf of Doug Barton"
<nanog-boun...@nanog.org on behalf of do...@dougbarton.us> wrote:

>On 12/18/2015 01:20 PM, Lee Howard wrote:
>>
>>
>> On 12/17/15, 1:59 PM, "NANOG on behalf of Matthew Petach"
>
>>> I'm still waiting for the IETF to come around
>>> to allowing feature parity between IPv4 and IPv6
>>> when it comes to DHCP.  The stance of not
>>> allowing the DHCP server to assign a default
>>> gateway to the host in IPv6 is a big stumbling
>>> point for at least one large enterprise I'm aware
>>> of.
>>
>>
>> Tell me again why you want this, and not routing information from the
>> router?
>
>C'mon Lee, stop pretending that you're interested in the answer to this
>question, and wasting everyone's time in the process. You know the
>answers, just as well as the people who would give them.

I’m flattered that you think I know so much.

Jared gave a useful reply, and I’m doing research before writing an
internet-draft.  


>
>>> Right now, the biggest obstacle to IPv6
>>> deployment seems to be the ivory-tower types
>>> in the IETF that want to keep it pristine, vs
>>> allowing it to work in the real world.
>>
>> There¹s a mix of people at IETF, but more operator input there would be
>> helpful. I have a particular draft in mind that is stuck between ³we¹d
>> rather delay IPv6 than do it wrong² and ³be realistic about how people
>> will deploy it."
>
>On this topic the operator input has been clear for over a decade, and
>yet the purists have blocked progress this whole time. The biggest
>roadblock to IPv6 deployment are its most ardent "supporters."

I don’t think IPv6 evangelists are in the way.
I do think many enterprises don’t care about IPv6, and no protocol changes
will make a difference. Some enterprise administrators wouldn’t mind
deploying IPv6 as long as they don’t have to think about it. I think this
is foolish: deploying a new Internet Protocol will not be simpler than
deploying a new Spanning Tree or a new routing protocol.
There are also enterprise administrators who have technical concerns;
those are the ones I want to help.

Lee

Re: IPv4 shutdown in mobile

[Lee Howard]

On 12/22/15, 1:13 PM, "NANOG on behalf of Owen DeLong"
 wrote:

>Yet until Apple gets to that IPv6-only stage, you¹re refusing to support
>IPv6 for those of us
>that need it today even while we still need IPv4, too.
>
>Owen


Owen, you¹re out of line.

Lee



>
>> On Dec 22, 2015, at 10:08 , Ca By  wrote:
>> 
>> 
>> 
>> On Tuesday, December 22, 2015, Owen DeLong >> wrote:
>> Does this mean you are negligent for not supporting IPv6 on my phone on
>>your network?
>> 
>> My phone is perfectly capable of IPv6, yet because it doesn¹t support
>>your particular religion
>> about IPv4 translation, you refuse to support IPv6 on it.
>> 
>> When is T-Mobile going to fix their IPv6 implementation and stop
>>ignoring the #1 market
>> leading phone manufacturer?
>> 
>> Owen
>> 
>> 
>> Apple has an ipv6-only plan in the link above. They have committed to
>>remove the ipv4 dependent apps from the app store. Once the ipv4-only
>>apps are bannished, i dont see any roadblocks for ipv6 on iPhone.
>> 
>> While you say there is a religious war, i am saying Apple outlined a
>>plan for ipv6-only and T-Mobile is likely to follow that plan from
>>Apple. 
>> 
>> CB
>> 
>>  
>> > On Dec 22, 2015, at 04:45 , Ca By >
>>wrote:
>> >
>> > TL;DR version: the data shows you are negligent if your eyeball
>>content
>> > (cdn, cloud, ...) does  not support native ipv6.
>> >
>> > With the NAT and IPv4 leasing threads lingering on, i figured it was
>>time
>> > for an update on how the other half live
>> >
>> > More than 1/3 of North America mobile traffic to the top websites is
>>end to
>> > end ipv6
>> > 
>>http://www.worldipv6launch.org/2015-wrapup-more-than-13-us-mobile-traffic
>>-is-ipv6-and-still-growing/
>>>c-is-ipv6-and-still-growing/>
>> >
>> > The trend is clearly growing, and as AT and Sprint catch up with
>>T-Mobile
>> > and Verizon, the acceleration to 50% should be easily achieved.
>> > Furthermore, only one mobile carrier has iPhone dual-stacked today
>>(afaik),
>> > but Apple has a plan for banning ipv4-only apps and has delivered the
>> > required features for having ipv6-only iphones in 2016 with these iOS
>>9.2
>> > features
>> >
>> > 
>>https://developer.apple.com/library/ios/documentation/NetworkingInternetW
>>eb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Trans
>>ition/UnderstandingandPreparingfortheIPv6Transition.html
>>>Web/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Tran
>>sition/UnderstandingandPreparingfortheIPv6Transition.html>
>> >
>> > On some mobile providers, ipv6 is already dominant and ipv4 is
>>waning. Once
>> > iPhones updates to ipv6-only as described above, ipv4 will only be a
>>corner
>> > case of operations.  This comes with added benefit that ipv6 is
>>faster :
>> >
>> > 
>>https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on
>>-board/ 
>>>n-board/>
>> >
>> > At least in mobile, the change to ipv6 has been quick and the pace is
>> > increasing -- not just on ipv6 deployment but also on ipv4 shutdown.
>>I know
>> > many people liken ipv6 to "the boy who cried wolf", so be it, the
>> > data shows the ipv6 wolf is here.  Or perhapsin hind   sight, we will
>>see
>> > the right metaphor was "the tortoise and the hare" or "the little
>>engine
>> > that could"... Or even better IPv4 is John Henry.  It was the best in
>>its
>> > time, but times have changed.
>> >
>> > CB
>> 
>
>

Re: IPv4 subnets for lease?

[Lee Howard]

Leasing is ill-advised; the addresses will be unsellable once the spammers
are through with them.
Really, there¹s no other reason to lease.

If you want to buy or sell addresses in the ARIN region, some of the
facilitators at 
https://www.arin.net/resources/transfer_listing/facilitator_list.html are
pretty good (ask me; I¹ll let you know my opinions privately).

The only ones I know who will deal in blocks as small as /24 are
http://www.ipv4auctions.com/
There may be others I don¹t know about.

Of course you have to ask whether IPv6 is a possible alternative, and you
shouldn¹t go to all the troule and expense of buying addresses without
turning up dual-stack. That would be like spending $20 for a tissue when
you need a $10 cold medicine; it helps, but not for long.

Lee


On 12/17/15, 9:31 PM, "NANOG on behalf of Nick Ellermann"
 wrote:

>We have customers asking to lease IP space for BGP transit with us and
>other peers. But they are struggling to get at a minimum even a Class C,
>even though they have their own ASN. We don't have large amounts of free
>IPv4 space to lease out to a single customer in most cases anymore. Hope
>to at least introduce these customers to some contacts that may be able
>to help.
>Do we know of any reputable sources that are leasing or selling IPv4
>subnets as small as a /24 to satisfy their diversity needs? Thanks!
>
>Sincerely,
>Nick Ellermann - CTO & VP Cloud Services
>BroadAspect
>
>E: nellerm...@broadaspect.com
>P: 703-297-4639
>F: 703-996-4443
>
>THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
>MATERIAL and is thus for use only by the intended recipient. If you
>received this in error, please contact the sender and delete the e-mail
>and its attachments from all computers.
>
>

Re: Nat

[Lee Howard]

On 12/17/15, 1:59 PM, "NANOG on behalf of Matthew Petach"
 wrote:

>On Wed, Dec 16, 2015 at 5:22 PM, Randy Bush  wrote:
>>> We need to put some pain onto everyone that is IPv4 only.
>>
>> this is the oppress the workers so they will revolt theory.
>
>Ah, yes, the workers are quite revolting!
>
>> load of crap.
>>
>> make ipv6 easier to deploy, especially in enterprise.  repeat the
>> previous sentence 42 times.
>
>
>I'm still waiting for the IETF to come around
>to allowing feature parity between IPv4 and IPv6
>when it comes to DHCP.  The stance of not
>allowing the DHCP server to assign a default
>gateway to the host in IPv6 is a big stumbling
>point for at least one large enterprise I'm aware
>of. 


Tell me again why you want this, and not routing information from the
router?


> Right now, the biggest obstacle to IPv6
>deployment seems to be the ivory-tower types
>in the IETF that want to keep it pristine, vs
>allowing it to work in the real world.

There¹s a mix of people at IETF, but more operator input there would be
helpful. I have a particular draft in mind that is stuck between ³we¹d
rather delay IPv6 than do it wrong² and ³be realistic about how people
will deploy it."

Lee

Re: Nat

[Lee Howard]

On 12/17/15, 2:27 PM, "NANOG on behalf of Chuck Church"
 wrote:

>-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Matthew Petach
>Sent: Thursday, December 17, 2015 1:59 PM
>Cc: North American Network Operators' Group 
>Subject: Re: Nat
>
>>I'm still waiting for the IETF to come around to allowing feature parity
>>between IPv4 and IPv6 when it comes to DHCP.
>
>And that recent thread on prefix delegation doesn't really leave a good
>taste in one's mouth about how to delegate a /56 or a /48 to a CPE, and
>get that/those prefix(s) in your (ISP) routing tables.  Given that
>99.999% of home users would be fine with a delegation of a single /64 and
>a single subnet I'm tempted to do that for now and let the DHCP-PD ink
>dry for a while so CPE support can follow up.

Which thread on which list?  DHCP-PD works to any home gateway that
supports IPv6. I know how the routing is set up in cable, don¹t know about
other access.
Or did you mean a prefix for a mobile device? Ongoing discussion in IETF
v6ops, with consensus that multiple addresses are needed.

There¹s disagreement among ISPs about what size prefix to delegate. So
what? Pick a number and do it. I don¹t know of anybody who thinks a /64 is
right for the home user, but I know of clueful people running every nibble
between /60 and /48. Pick a number, plan so you can change it later, and
deploy.

Lee

>
>Chuck
>
>

Re: Nat

[Lee Howard]

On 12/16/15, 8:53 PM, "NANOG on behalf of Berry Mobley"
 wrote:

>At 08:22 PM 12/16/2015, Randy Bush wrote:
>> > We need to put some pain onto everyone that is IPv4 only.
>>
>>this is the oppress the workers so they will revolt theory.  load of
>>crap.
>>
>>make ipv6 easier to deploy, especially in enterprise.  repeat the
>>previous sentence 42 times.
>
>This. I'm in an enterprise with some stubborn vendors, and none of
>them are even talking about ipv6. It won't help me to move (and it
>won't help you to get well if you're here) if my users can't get to
>their stuff.


Can you dual-stack while you wait for them?
Can we help you push on those vendors?

Lee

>
>Berry 
>
>

Re: Nat

[Lee Howard]

On 12/16/15, 7:14 PM, "NANOG on behalf of Mel Beckman"
 wrote:

>Mark,
>
>Why? Why do WE "need" to force people to bend to our will? The market
>will get us all there eventually.

Some companies will run out of IPv4 addresses before others. When that
happens, they have four choices:

1. Buy IPv4 addresses. But supply is going; in a couple of years, there
will be nothing larger than a /16. And this raises costs, and therefore
consumer prices.
2. Address sharing. Breaks p2p, some other things.
3. Address family translation. Breaks several things.
4. IPv6-only. Means only IPv6-enabled content is available.

That¹s why some values of $we ³need² to force people to deploy IPv6: so
$we don¹t screw consumers and break the Internet.

But those with IPv4 addresses see exhaustion as someone else¹s problem.
They don¹t care if somebody else¹s prices go up, unless they¹re the ones
blamed for the rising prices. (³You have to pay more for Internet access
or you won¹t be able to reach Amazon or eBay.²)
They might not like the performance of address sharing/translation, but if
they wait until they notice the pain, and it takes them two years to
respond, they¹re already in serious trouble.

There is still time for companies without IPv6 to get it deployed before
going out of business. But anyone who isn¹t done two years from now is in
trouble.

Lee

Re: /27 the new /24

[Lee Howard]

On 10/12/15, 1:49 PM, "NANOG on behalf of Mike"  wrote:

>
>Thats not even the half of it.
>
>My personal heroics in solving the connectivity problem here, is that we
>became a CLEC in order to take the bull on by the short and curlys and
>build facilities. But the problem is even bigger than just getting dark
>fiber strands and collocating in a few select telco offices; My entire
>county is woefully underserved. Connectivity here is expensive as all
>hell. So on top of the nearly $1mln now sunk in this part of the
>venture, I am STILL looking at several more $$mln to build out of this
>dank hole and connect up at those carrier hotels in the far off fantasy
>world where connectivity options abound.

You have my sympathies. Which gets you nothing but consolation.

>
>> It sounds like you do have some concern about the transition, and you
>> know there¹s a bug, at least with OS downloads. Please do report those
>> issues you know about. Usually, Happy Eyeballs masks problems in dual
>> stack, whether that¹s good or bad. If we can get your upstream(s) to
>> support IPv6, then maybe we can leverage them to help troubleshoot MTU
>> problems, so you don¹t have to spend a lot of time on them. Or maybe
>> they go away when you¹re no longer tunnelling.
>
>No, the problem is that v6 isn't ready for prime time. Period.

That statement is too broad. Lots of companies are using IPv6 in prime
time.

There may be some features with some bugs. I don’t know how we shake those
out if people don’t try those features and report the bugs.

>
 I can't remember the last time I saw a site stall due to reaching it
 over IPv6 it is that long ago.
>>> It happens every day for me, which only amplifies my perception that v6
>>> IS NOT READY FOR PRIME TIME.
>> Would you at least keep a list of places you have these problems, even
>>if
>> you never follow up on it? Again, I¹m wondering if tunnelling is the
>> problem, and once you have native dual-stack, you could refer to the
>>list
>> and see if problems just dry up.
>
>No, the problem is that v6 isn't ready for prime time, period. Im not
>going to consider rolling it out to my customers until the point comes
>where it stops going down and stops malfunctioning and stops being 'a
>problem' that has to be dealt with by disabling the v6 stack on the
>afflicted host. Until then, it's going to continue to be treated as
>academic masturbation likely to be replaced with something competently
>designed based on technical merits alone.

IPv4 malfunctions, too. I haven’t seen anything to suggest that IPv6 is
less robust than IPv4. One does have to climb the learning curve and
develop support processes, but that’s true with anything, including IPv4.


> Damm maddening. Can't imagine the screaming I'll
> hear if a home user ever ran into similar so I am quite gun shy about
> the prospect. Secondly, the the dodgy nature of the CPE connected to
> our
> network and the terminally buggy fw they all run is sure to be a
>never
> ending source of stupidity.
 CPE devices are buggy for IPv4 as well.  Bugs in CPE devices are
 only found and fixed if the code paths are exercised.
>>> Not my job. v4 works, v6 does not. I am a provider not a developer.
>> I would guess it is your job in IPv4.
>> I would also guess, based on gateways I¹ve seen, than 10% of CPE
>> has critical IPv4 bugs, and 25% of CPE has critical Ipv6 bugs. I agree
>>with
>> you that the difference is too high, and maybe waiting a year helps get
>> those ratios aligned.
>>
>> CPE vendors: step it up!
>
>I think the major pain points in CPE gear is really less than 'ipv4'
>bugs and more just bad design in general. They 'lock up' and stop
>forwarding, requiring end users to 'power cycle' the equipment in order
>to attain functionality again. And, they still stupidly have a 'reset'
>button, which users still think will help them when it's "locked up" but
>in fact simply "wipes out required settings", causing further problems
>for the poor hapless user. They are quite big on shiny flashing lights
>and starship or battle ship shaped plastic housings, but long term
>reliability is about as good as trusting v6 for anything, which is to
>say they are not trustworthy at all.

So, CPE is buggy and sucks. I wish there was money to be made in
delivering quality CPE code.


>>
>> Figure out how long until you think you really need all of your
>>customers
>> to have IPv6. Subtract your CPE replacement time. Start replacing CPE
>>then.
>> e.g., if users need IPv6 in 2018, and you replace all CPE on a 5 year
>> schedule, you should begin providing IPv6-capable CPE in 2013.
>>
>
>Again, requires me to be a developer and not a provider. Working CPE do
>not exist yet.

You said above that you thought that CPE reliability is as good as IPv6.
There are quite a few models that work as well with IPv6 as IPv4. But not
all.

But I didn’t ask you to be a 

Re: /27 the new /24

[Lee Howard]

On 10/8/15, 6:45 PM, "NANOG on behalf of Mike"  wrote:

>
>
>On 10/08/2015 02:41 PM, Mark Andrews wrote:
>>
>>
>> Plus one to that. We are such a provider, and IPv6 is on my list of
>> things to implement, but the barriers are still plenty high. Firstly, I
>> do have an Ipv6 assignmnt and bgp (v4) and an asn, but until I can get
>> IPv6 transit,
>>
>> There are lots of transit providers that provide IPv6.  It really is
>> time to name and shame transit providers that don't provide IPv6.
>
>NO, THERE IS NOT. We operate in rural and underserved areas and WE DO
>NOT HAVE realistic choices. Can you see me from your ivory tower?

I looked up tiedyenetworks.com, and I think he¹s 100 miles from Sacramento.
I hope some sales person from a transit provider is giving him a call right
now, but it¹s entirely possible that there are no big providers in his
neighborhood. Sorry, Mike, wish I could help you there.

However, you can still mock your upstreams here. Then we can offer them
help to support IPv6.

>
>>> there is not much point in my putting a lot of effort into
>>> enabling IPv6 for my subscribers. Yes I have a HE tunnel and yes it's
>>> working, but it's not the same as running native v6 and with my own
>>> address space. Second, on the group of servers that have v6 thru the HE
>>> tunnel, I still run into problems all the time where some operations
>>> over v6 simply fail inexplictly, requireing me to turn off v6 on that
>>> host so whatever it is I'm doing can proceed over v4.
>>> Stuff like OS updates for example.
>> Then complain to the OS vendor.  It is most probably someone breaking
>> PMTU discover by filtering PTB.  Going native will hide these
>> problems until the MTU between the DC and the rest of the net
>> increases.  You could also just lower the advertised MTU internally
>> to match the tunnel MTU which would let you simulate better what a
>> native experience would be.
>Not my job. v4 works, v6 does not, end of story.

It sounds like you do have some concern about the transition, and you know
there¹s a bug, at least with OS downloads. Please do report those
issues you know about.

Usually, Happy Eyeballs masks problems in dual stack, whether that¹s good
or bad. 

If we can get your upstream(s) to support IPv6, then maybe we can leverage
them to help troubleshoot MTU problems, so you don¹t have to spend a lot
of time on them. Or maybe they go away when you¹re no longer tunnelling.

>
>>
>> I can't remember the last time I saw a site stall due to reaching it
>> over IPv6 it is that long ago.
>
>It happens every day for me, which only amplifies my perception that v6
>IS NOT READY FOR PRIME TIME.

Would you at least keep a list of places you have these problems, even if
you never follow up on it? Again, I¹m wondering if tunnelling is the
problem, and once you have native dual-stack, you could refer to the list
and see if problems just dry up.

>
>>> Damm maddening. Can't imagine the screaming I'll
>>> hear if a home user ever ran into similar so I am quite gun shy about
>>> the prospect. Secondly, the the dodgy nature of the CPE connected to
>>>our
>>> network and the terminally buggy fw they all run is sure to be a never
>>> ending source of stupidity.
>> CPE devices are buggy for IPv4 as well.  Bugs in CPE devices are
>> only found and fixed if the code paths are exercised.
>
>Not my job. v4 works, v6 does not. I am a provider not a developer.

I would guess it is your job in IPv4.
I would also guess, based on gateways I¹ve seen, than 10% of CPE
has critical IPv4 bugs, and 25% of CPE has critical Ipv6 bugs. I agree with
you that the difference is too high, and maybe waiting a year helps get
those ratios aligned.

CPE vendors: step it up!

>> That said IPv6 worked fine for me with the shipped image (old version
>> of OpenWRT) using 6to4 before I reflashed it to a modern version
>> of OpenWRT as I wanted to use the HE tunnel rather than 6to4.  I
>> know that is only one CPE device.
>  And will you be providing all of my end users with replacement CPE
>that meets all of the other requirements too? No? Because no such
>devices exist yet? OHHH yeah thats right, I'm a provider not a
>developer, so again, not a solution for my business.

Ugh, 6to4 is a bad idea anyway. Deprecated, even.
There are loads of gateways that support native dual-stack and several
transition mechanisms (DS-lite, 6rd, and MAP pretty soon), but native
dual-stack is the way to go if you possibly can.
If you provide gateways as part of your service, you should at least make
sure you¹re providing devices that at least *claim* IPv6 support now (and
the IPv6 CPE Ready logo is meaningful here), so that as old equipment
ages out, you¹re not stuck replacing newer boxes.

Figure out how long until you think you really need all of your customers
to have IPv6. Subtract your CPE replacement time. Start replacing CPE then.
e.g., if users need IPv6 in 2018, and you replace 

Re: another tilt at the Verizon FIOS IPv6 windmill

[Lee Howard]

On 7/17/15, 6:25 AM, Christopher Morrow christopher.mor...@gmail.com on
behalf of morrowc.li...@gmail.com wrote:

On Wed, Jul 15, 2015 at 4:43 PM, Ricky Beam jfb...@gmail.com wrote:
 On Wed, 15 Jul 2015 16:20:11 -0400, Lee Howard l...@asgard.org wrote:

 Business Class DOCSIS customers get a prefix automatically (unless you
 provide your own gateway and DHCPv6 isn¹t enabled).


doesn't the last paranthetical here


 I looked last night at the office in Cary, NC. NO RAs are seen on the
link
 coming from the Ubee (bridged) providing our dynamic/DOCSIS connection.
 Without an RA, nothing will attempt IPv6.


mean that your UBee has to do dhcpv6? (or the downstream thingy from
the UBee has to do dhcpv6?)

Yes.

I should have said that there are some modems that don’t support IPv6, and
a few that should-but-don’t-properly-yet. Ricky and I have corresponded
privately.

Lee



 (I've not checked the one in Raleigh that's also a hotspot)

 Residential? sure, there's lot of v6 there -- has been for over a year.
But
 as I'm an Earthlink customer, and those morons cannot be bothered to
give
 TWC one of their *5* UNUSED /32's, all I get is:
 (IA_PD IAID:327681 T1:0 T2:0 (status code no prefixes))

 --Ricky

Re: Dual stack IPv6 for IPv4 depletion

[Lee Howard]

On 7/16/15, 11:24 AM, NANOG on behalf of Joe Maimon
nanog-boun...@nanog.org on behalf of jmai...@ttec.com wrote:



To clarify, my criticism of top down is specifically in response to the
rationale presented that it is a valid objective to prevent, hinder and
refuse to enable efforts that compete with ipv6 world-takeover
resources.

I don¹t see anybody hindering any efforts; I don¹t see any efforts.


I have no intention of using Class E. I have no intention of developing
code that uses Classe E. I will note that the code involved that is
publicly searchable appears to be simple and small, the task that is
large is adoption spread.

So this argument is moot?


But perhaps we can all agree that standards should be accurate and
should not be used to advance uninvolved agenda. And class E
experimental status is inaccurate. And keeping that status serves
nobody, except those who believe it helps marshal efforts away from
IPv4. And that is top down.

So, you would like to update RFC 1112, which defines and reserves Class E?
That¹s easy enough. If somebody had a use in mind for the space, anybody
can write such a draft assigning space, which is, I believe, how to
direct IANA to do something with it.

If you want to direct IANA to distribute Class E space among the RIRs,
there¹s more process, because you would also have to develop a global
policy (no problem, we get the NRO NC to write it and get consensus at
all the RIRs), and then each RIR would need to develop a policy under
which to allocate it. I¹d be surprised if all that could happen in
less than three years.

In any of these processes, nothing will move forward until there is
consensus, and I don¹t think there¹s consensus. If you think your
argument can be persuasive, let¹s write an internet-draft and get it
into the process.

Lee


Joe

Re: 'gray' market IPv4

[Lee Howard]

On 7/16/15, 12:47 PM, NANOG on behalf of Bryan Fields
nanog-boun...@nanog.org on behalf of br...@bryanfields.net wrote:

On 7/15/15 9:59 AM, Lee Howard wrote:
 Price varies significantly by prefix length, and somewhat by region.
 Regional variance may not be as much as it used to be.

Does legacy space command a premium in this?

From what I understand, and I have not been a party to any transactions,
there are differences in transaction where the space looks ³cleaner.² That
is, space that has been less delegated, and has never appeared an a spam
blacklist. I don¹t know whether that translates to higher prices, or
whether buyers just won¹t buy questionable space.


What's the going rate to lease space (say a /20 or /19 for discussion)?

Leases aren¹t worth the trouble, because sellers believe that the only
reason for a temporary lease is to originate spam, following which the
address space is worthless. So if you can find a lease at all, it is
likely to cost as much or more than buying outright. Personally, I
wouldn¹t lease space at all, because I wouldn¹t want my organization¹s
name anywhere near it when the bad stuff started happening.
The ipv4auctions.com site lists prefixes that large; recent /20s have been
$7.45-$8.00 per address.

Bear in mind that I¹m essentially a researcher, and have no direct
experience. You might want to talk to a broker or three.

Lee


-- 
Bryan Fields

727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net

Re: Dual stack IPv6 for IPv4 depletion

[Lee Howard]

On 7/16/15, 4:32 PM, Joe Maimon jmai...@ttec.com wrote:



Lee Howard wrote:

 So, you would like to update RFC 1112, which defines and reserves Class
E?
 That¹s easy enough. If somebody had a use in mind for the space, anybody
 can write such a draft assigning space, which is, I believe, how to
 direct IANA to do something with it.


nope

“Nope?”
You mean you don’t want to update RFC1112?
Or it’s not possible for somebody to write a draft telling IANA to assign
space
for an experiment? Somebody has to write a draft in order for the IETF to
consider it, and there has to be IETF consensus for it to get published as
an
RFC. 


http://packetlife.net/blog/2010/oct/14/ipv4-exhaustion-what-about-class-e-
addresses/

All the same rationals, including how it might be bad for ipv6, its too
late, its too hard, its too little were trotted out then, just as now.

I don’t see the relevance. Nobody there proposed reclassifying the space.
Nobody had a proposal for an experiment. Nobody wanted an assignment from
it.



The only use I have in mind for the space is for it to cease being
classified as experimental and therefore treated as invalid.

You want the word “RESERVED” for some entries on this page changed:
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
What do you want it changed to?


 If you want to direct IANA to distribute Class E space among the RIRs,
 there¹s more process, because you would also have to develop a global
 policy (no problem, we get the NRO NC to write it and get consensus at
 all the RIRs), and then each RIR would need to develop a policy under
 which to allocate it. I¹d be surprised if all that could happen in
 less than three years.

I would not care about that, so long as the impediment, the experimental
status was removed. Let the stakeholders have a real shot.

There’s more to it than that.
How would people who want to use it get assignments?
Right now, there’s no policy for assigning that space.


You’ve told other people that there shouldn’t be a top-down restriction on
this space; but there’s no top: it’s all consensus. The consensus here is
very clear. You are welcome to try to change it, and a couple of us are
trying to should you the processes (IETF, IANA, RIR) to do that.


If all you want to do is vent, we’ll just move on to another thread.

Lee

Re: another tilt at the Verizon FIOS IPv6 windmill

[Lee Howard]

On 7/13/15, 3:43 PM, NANOG on behalf of Ricky Beam
nanog-boun...@nanog.org on behalf of jfb...@gmail.com wrote:

On Sun, 12 Jul 2015 17:32:33 -0400, Ca By cb.li...@gmail.com wrote:
 Yes, move your business to TWC. TWC  has a proven v6 deployment and is
 actively engaged in the community, as where vz Fios is not.

Yes, because TWC-BC's IPv6 support is stellar. Sorry, I misspelled
non-existent.

Business Class DOCSIS customers get a prefix automatically (unless you
provide your own gateway and DHCPv6 isn¹t enabled). Since it¹s dynamic, it
might change; working on providing stable prefixes.
http://www.timewarnercable.com/en/support/internet/topics/ipv6.html


Their DIA (metro-e) stuff, *might*, but I doubt it.


Does, but since it requires BGP or static route configuration, you have to
ask.

Lee

Re: ARIN IPV4 Countdown

[Lee Howard]

On 7/14/15, 11:16 PM, NANOG on behalf of Randy Bush
nanog-boun...@nanog.org on behalf of ra...@psg.com wrote:

 While the base curve it runs on is running ahead of the measured traffic
 curve, the measure of IPv6 enabled browsers is a reasonable indicator
for
 what is happening.

we're an isp, with ipv6 enabled since 1997.  we measure real traffic,
not wishes of what could be.

I don¹t know how much of your traffic is IPv6, but ³10% by the time we
retire² sure looks like a prediction. If it¹s number of users, that¹s well
above 10%. IPv6 support in a couple of video streaming devices would push
it well past that.

I hope you¹re right about retiring at 10%‹it would be great to have the
resources to retire this year.

Lee


randy

Re: 'gray' market IPv4

[Lee Howard]

Price varies significantly by prefix length, and somewhat by region.
Regional variance may not be as much as it used to be.

Lee

On 7/14/15, 6:15 PM, NANOG on behalf of Pavel Odintsov
nanog-boun...@nanog.org on behalf of pavel.odint...@gmail.com wrote:

Hello, folks!

I have finished multiple (and 5th in RIPE) inter RIR subnet moves in RIPE
region. We have moved multiple /21-/20 networks and awerage cost was about
$10 per ip.

On Tuesday, July 14, 2015, Martin Hannigan hanni...@gmail.com wrote:

 On Tue, Jul 14, 2015 at 10:22 AM, Matt Kelly mjke...@gmail.com
 javascript:; wrote:

  This list is actual sale prices,
  http://www.ipv4auctions.com/previous_auctions/
 
 
  --
  Matt
 
 
  On July 14, 2015 at 10:14:05 AM, Justin Wilson - MTIN (li...@mtin.net
 javascript:;)
  wrote:
 
  Thes folks (and I am not advertising or affiliated with them) publish
a
  list of most recent transfer completed:
 
  http://ipv4marketgroup.com/broker-services/buy/
 
 
 http://ipv4marketgroup.com/broker-services/buy/  vs.
 http://www.ipv4auctions.com/previous_auctions/


 If you compare the pricing that both have made available you will find
one
 is posting average prices exponentially higher than the other. When you
 trend the granular auction site data the auction numbers demonstrate a
 trend  would expect, that smaller prefixes are more expensive since it
 takes a similar amount of effort to process a /24 as it does a /20.
Dollar
 differences between a  /24 unit and a /17 unit move the needle
 significantly.

 Based on both of both sets of public data its easy to conclude that
 auctions will work for at least small buyers of space if they're
 sophisticated enough to address the RIR issues. If you do decide to take
 the simple broker approach (not all are simple and not all approaches
are
 suitable to simple brokers), use an RFP.  And Yelp. :-)

 Best,

 -M



-- 
Sincerely yours, Pavel Odintsov

Re: Remember Internet-In-A-Box?

[Lee Howard]

I google¹d ³IPv6 for Dummies² and found this:
https://www.wesecure.nl/upload/documents/tinymce/IPv6.pdf
It¹s licensed from the For Dummies series, written and published by
Infoblox.

more below. . .

On 7/14/15, 8:02 PM, NANOG on behalf of Mike nanog-boun...@nanog.org on
behalf of mike-na...@tiedyenetworks.com wrote:



On 07/14/2015 04:46 PM, Stephen Satchell wrote:
 This goes back a number of years.  There was a product that literally
 was a cardboard box that contained everything one needed to get
 started on the Internet.  Just add a modem and a computer, and you
 were on your way.  No fuss, no learning curve.

 I'm beginning to think that someone needs to create a similar product,
 but for IPv6 internet.  The Internet service providers would provide
 the same sort of kit to get people started.  Just add a CSU/DSU (like
 a cable modem) and a computer, and you are on your way.

 Also, I think we need a *real* book called IPv6 for Dummies (maybe
 even published by IDG Books) that walks through all the beginner
 stuff.  There's beginner stuff that I've seen by using a search
 engine; a dead-tree book, though, may well be better for Joe Average.

 Just my pair-o-pennies(tm)



I am a small provider with a 16 bit asn, a /20 and a /22 of ipv4 and a
/32 of v6, but no clue yet how to get from where I am today to where we
all should be. The flame wars and vitrol and rhetoric is too much noise
for me to derive anything useful from. Someone needs to stand up and
lead. I will happily follow.

I also co-authored RFC6782, intended to be guidance for landline ISPs
deploying IPv6:
http://tools.ietf.org/html/rfc6782
We really tried to make it step-by-step, and you don¹t necessarily need
to hit each step (as we explain in the document).


Whats really needed, is for you gods of ipv6, to write that 'ipv6 for
ipv4 dummies', targeting service providers and telling us exactly what
we need to do. No religious wars about subnet allocation sizes or dhcpv6
vs slaac or anything. Tell us how to get it onto our network, give us
reasonable deployment scenarios that leverage our experience with IPv4
and tell us what we are going to tell our customers. Help us understand
WHY nat is not a security model, and how to achieve the same benefits we
have with nat now, in an ipv6 enabled world.

Send me private email and we can set up time to talk. I won¹t know the
IPv6 capabilities of every piece of equipment you have, but I might be
able to help you plan.

Lee



Mike

Re: Remember Internet-In-A-Box?

[Lee Howard]

On 7/15/15, 11:57 AM, NANOG on behalf of Matthew Kaufman
nanog-boun...@nanog.org on behalf of matt...@matthew.at 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.

This is painfully true.
I don¹t have much sympathy for Windows XP, since it¹s a year past extended
End of Support, and it¹s a 15-year-old operating system, now five
generations obsolete?
But specific-purpose consumer electronics are failures: not just cameras,
but game consoles, set-top boxes, audio-video systems.
Even security critical stuff like software updates, anti-virus updates,
CRL checks, are almost completely unavailable over IPv6. Unless you run a
large enough enterprise to have your own update servers; then they can
pull updates over IPv4, and serve clients over IPv6.

However, if you dual-stack now, you¹ll be able to identify which things
are still dependent on IPv4, and either engineer differently, or
substitute equipment over time.

Lee



Matthew Kaufman

Re: Hotels/Airports with IPv6

[Lee Howard]

On 7/9/15, 11:04 AM, NANOG on behalf of Mel Beckman
nanog-boun...@nanog.org on behalf of m...@beckman.org wrote:

I working on a large airport WiFi deployment right now. IPv6 is allowed
for in the future but not configured in the short term. With less than
10,000 ephemeral users, we don't expect users to demand IPv6 until most
mobile devices and apps come ready to use IPv6 by default.

I didn¹t see anybody point out that most mobile devices and apps come
ready to use IPv6 by default.
At least, all Android and iOS devices do, and Apple recently announced
that IPv6 support will be mandatory in future apps.
Plus, Facebook, at least, says IPv6 is faster over mobile. Don¹t know how
it does over Wi-Fi.

Lee

Re: Dual stack IPv6 for IPv4 depletion

[Lee Howard]

Some thoughts. . .

³Native dual-stack² is ³native IPv4 and native IPv6.²

³Dual-stack² might be native, or might by ³native IPv6 plus IPv4 address
sharing.²

Your IPv4 address sharing options are CGN, DS-Lite, and MAP. There are
operational deployments of all three, in the order given. You need them
close enough to your customers that traffic will return over the same
path. You can¹t share state among a cluster of boxes, but that¹s not the
end of the world; a device failure sometimes causes loss of state. MAP is
the hot new thing all the cool kids are doing.

Look to your router and load balancer vendors for devices that do these.
CGN is the only one that doesn¹t require updates to the home gateway. The
more IPv6 your customers use, the smaller your CGN/AFTR/MAP can be.

Think about how you¹ll position it to customers. It¹s difficult to change
a customer¹s service mid-contract. At some point, a customer is no longer
profitable: if NAT costs and service calls add up, you may be better off
buying addresses or losing the customer. You may need to buy some IPv4
addresses to give you time; contact a broker.

You may be surprised how hard it is to root IPv4 out of the system. Don¹t
buy anything you can¹t manage over IPv6, including servers and
applications. Sorry, vendor, I can¹t buy your cluster, I don¹t have the
IPv4 address space to provision it.

Lee

On 7/4/15, 8:09 AM, NANOG on behalf of Josh Moore
nanog-boun...@nanog.org on behalf of jmo...@atcnetworks.net 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. Current dual stack best
practices seem to recommend deploying BOTH IPv4 and IPv6 to every CPE. If
this is the case, and BOTH are still required, then how does IPv6 help
with the v4 address depletion crisis? Many sites and services would still
need legacy IPv4 compatibility. Sure, CGN technology may be a solution
but what about applications that need direct IPv4 connectivity without
NAT? It seems that there should be a mechanism to enable on-demand and
efficient IPv4 address consumption ONLY when needed. My question is this:
What, if any, solutions like this exist? If no solution exists then what
is the next best thing? What would the overall IPv6 migration strategy
and goal be?

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.


Thanks

Joshua Moore
Network Engineer
ATC Broadband
912.632.3161

Re: Thanks aws / gcc / azure

[Lee Howard]

On 6/23/15, 9:01 AM, NANOG on behalf of Ca By nanog-boun...@nanog.org
on behalf of cb.li...@gmail.com wrote:

Since you have failed to achieve in the modest task that was your charge

You now get this

https://www.markshuttleworth.com/archives/1471

Time to watch this again: https://www.youtube.com/watch?v=v26BAlfWBm8

Lee


Or s/money/addresses/

http://youtu.be/pA8f-Nh5gRs

Re: AWS Elastic IP architecture

[Lee Howard]

On 6/1/15, 1:49 PM, Matthew Kaufman matt...@matthew.at wrote:

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.

³fraction² is nearly 1/5 in the U.S., and growing fast:
https://www.vyncke.org/ipv6status/project.php
I don¹t know your source for ³often being worse,² but I have several
sources saying, ³lower latency.² (see NANOG60, IPv6 Performance Panel, and
see Facebook¹s numbers from World IPv6 Congress).


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.

For certain values of ³everyone.²


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)

I agree with that.

Lee



Matthew Kaufman

Re: BCOP appeals numbering scheme -- feedback requested

[Lee Howard]

On 3/13/15 5:14 PM, m...@becknet.com m...@becknet.com wrote:

Lee,

On the contrary, I think RFCs are pretty consistent about always
referring you to any superseding RFCs, and superseding RFCs reference
their predecessors, creating a very useful historical doubly-linked list.
I've served on IEEE committees that follow a decimal/alpha/french
numbering system, in which it is very hard to track the history of a
standard. 

RFCs, on the other hand, tend to be concisely written and well annotated
with background materials. What's more, RFC makes an excellent unique
internet-global search term.

You've made the assertion that RFC numbering is terrible.  Can you
provide some examples?

The canonical version of the RFC is the plain text version.
So here's RFC6204:
http://www.rfc-editor.org/rfc/rfc6204.txt
No notes about being obsolete.

If you want, you can find two other versions officially published, the
tools version and the datatracker version:
https://tools.ietf.org/html/rfc6204
https://datatracker.ietf.org/doc/rfc6204/
Both of those tell you that this RFC has been obsoleted by RFC7084.



But here's one: https://tools.ietf.org/html/rfc791
Let's say I want to implement this protocol.  Looks pretty
straightforward, once I've read the errata and the three RFCs that
obsolete it.
The first of those three is RFC1349, which also has been obsoleted by
RFC2474, which in turn has been obsoleted by RFC3168 and RFC3260, the
first of which is obsoleted by RFC4301 and RFC6040.  I didn't follow the
other chains of obsoleting documents.  How many documents do I have to
read if I want to implement this protocol?

Ha, ha, you say, nobody's trying to write an IP implementation from
scratch. Au contraire, IPv6 is defined in
https://tools.ietf.org/html/rfc2460, which lists nine RFCs updating it,
plus errata.

And while I agree with you that RFC2460 is an easy, unique search term,
it isn't exactly memorable. I need to write an IPv6 stack for my new
ThingOS; what do I need to read?  And one of my least favorite comments
at the mic at IETF is, Have you even read RFC6214? [1] Because the
author is standing there with no way to look up what that particular
number means.
 
I know, I should really be having this rant in the RFC evolution WG, or
with the RFC editor. It just came up here, and I want BCOP to make
different mistakes on useful documents.

Lee


[1] I included this reference in an RFI, to catch vendors who were only
cutting and pasting marketing materials.


 -mel beckman

 On Mar 13, 2015, at 12:50 PM, Lee Howard l...@asgard.org wrote:
 
 I think the RFC numbering system is a terrible scheme.  As Wes
described,
 you have a document purporting to describe something, with no indicator
 that parts of it have been rendered obsolete by parts of other
documents.
 I pity implementors who have to figure it all out.
 
 I also agree with Joel, that assigning meaning to index numbers is a bad
 idea. It leads to crossed indexes and unclear references.
 
 For the documents to be useful, one should be able to read a single
 document on a topic. When that topic is too big for a single document,
 split the document. When something in one document supersedes something
in
 another, confirm consensus and update the canonical document.
 
 If that's too dynamic for people, then maintain the index, and when part
 of a document is obsoleted, the entire updated document should be
 republished with a new number, and the old one marked obsoleted by
.
 
 Under no circumstances would I support a limited number space.
 
 Lee
 
 On 3/13/15 2:26 PM, Mel Beckman m...@beckman.org wrote:
 
 The index scheme has worked very well with RFCs, and has the added
 advantage of their index numbers becoming handy memes. I strongly urge
 Nanog to take advantage of the RFC system's success. There is no
shortage
 of monotonically ascending integers :)
 
 -mel beckman
 
 On Mar 13, 2015, at 11:19 AM, Rick Casarez rick.casa...@gmail.com
 wrote:
 
 I like the idea of an index better than the proposed numbering scheme.
 
 ---
 Cheers, Rick
 
 Experiences not things.
 
 On Thu, Mar 12, 2015 at 7:48 PM, Owen DeLong o...@delong.com wrote:
 
 
 On Mar 12, 2015, at 12:01 , Yardiel D. Fuentes yard...@gmail.com
 wrote:
 
 
 
 Hello NANOGers,
 
 The  NANOG BCOP committee is currently considering strategies on how
 to
 best create a numbering scheme for the BCOP appeals. As we all know,
 most
 public technical references (IETF, etc) have numbers to clarify
 references.
 The goal is for NANOG BCOPs to follow some sort of same style.
 
 The BCOP committee is looking for feedback and comments on this
topic.
 
 Currently, the below numbering scheme is being considered:
 
 A proposed numbering scheme can be based on how the appeals appeals
in
 the BCOP topics are presented as shown below:
 
 http://bcop.nanog.org/index.php/Appeals
 
 In the above page, the idea is to introduce a 100-th range for each
 category and as the BCOPs. This way a 100th number range

Re: BCOP appeals numbering scheme -- feedback requested

[Lee Howard]

I think the RFC numbering system is a terrible scheme.  As Wes described,
you have a document purporting to describe something, with no indicator
that parts of it have been rendered obsolete by parts of other documents.
I pity implementors who have to figure it all out.

I also agree with Joel, that assigning meaning to index numbers is a bad
idea. It leads to crossed indexes and unclear references.

For the documents to be useful, one should be able to read a single
document on a topic. When that topic is too big for a single document,
split the document. When something in one document supersedes something in
another, confirm consensus and update the canonical document.

If that's too dynamic for people, then maintain the index, and when part
of a document is obsoleted, the entire updated document should be
republished with a new number, and the old one marked obsoleted by .

Under no circumstances would I support a limited number space.

Lee

On 3/13/15 2:26 PM, Mel Beckman m...@beckman.org wrote:

The index scheme has worked very well with RFCs, and has the added
advantage of their index numbers becoming handy memes. I strongly urge
Nanog to take advantage of the RFC system's success. There is no shortage
of monotonically ascending integers :)

 -mel beckman

 On Mar 13, 2015, at 11:19 AM, Rick Casarez rick.casa...@gmail.com
wrote:
 
 I like the idea of an index better than the proposed numbering scheme.
 
 ---
 Cheers, Rick
 
 Experiences not things.
 
 On Thu, Mar 12, 2015 at 7:48 PM, Owen DeLong o...@delong.com wrote:
 
 
 On Mar 12, 2015, at 12:01 , Yardiel D. Fuentes yard...@gmail.com
 wrote:
 
 
 
 Hello NANOGers,
 
 The  NANOG BCOP committee is currently considering strategies on how
to
 best create a numbering scheme for the BCOP appeals. As we all know,
most
 public technical references (IETF, etc) have numbers to clarify
references.
 The goal is for NANOG BCOPs to follow some sort of same style.
 
 The BCOP committee is looking for feedback and comments on this topic.
 
 Currently, the below numbering scheme is being considered:
 
 A proposed numbering scheme can be based on how the appeals appeals in
 the BCOP topics are presented as shown below:
 
 http://bcop.nanog.org/index.php/Appeals
 
 In the above page, the idea is to introduce a 100-th range for each
 category and as the BCOPs. This way a 100th number range generally
 identifies each of the categories we currently have. An example is:
 
 BCP Range Area of Practice
 100 - 199 EBGPs
 200 - 299 IGPs
 300 - 399 Ethernet
 400 - 499 Class of Service
 500 - 599 Network Information Processing
 600 - 699 Security
 700 - 799 MPLS
 800 - 899 Generalized
 
 An arguable objection could be that the range is limited...but a
 counter-argument is that considering more than 100 BCOPs would be
either a
 great success or just a sign of failure for the NANOG community ...
 
 Comments or Thoughts ?
 
 The problem with any such numbering scheme is how you handle the
situation
 when you exhaust the avaialble number space. What happens with the
101st
 EBGP BCOP, for example?
 
 I also agree with Joel¹s comment about identifier/locator overload.
Have
 we learned nothing from the issues created by doing this in IPv4 and
IPv6?
 
 Instead, how about maintaining a BCOP subject index which contains
titular
 and numeric information for each BCOP applicable to the subjects above.
 
 e.g.:
 
 BCOP Subject Index:
 
 Subjects:
1.  EBGP
2.  IGP
3.  Ethernet
4.  Class of Service
5.  Network Information Processing
6.  Security
7.  MPLS
8.  Generalized
 
 
 1.  EBGP
104 lorem ipsum
423 ipsum lorem
 
 
 
 Then, just like the RFCs, maintain the BCOP appeal numbering as a
 sequential monotonically increasing number and make the BCOP editor
 responsible for updating the index with the publishing of each new or
 revised BCOP.
 
 Note, IMHO, a revised BCOP should get a new number and the previous
 revision should be marked ³obsoleted by X² and it¹s document status
 should reflect ³Obsoletes , , and ² for all previous
revisions.
 The index should probably reflect only BCOPs which have not been
obsoleted.
 
 Just my $0.02.
 
 Owen
 
 

Public Policy Approaches to IPv4-IPv6 Transition

[Lee Howard]

If you are a monarch or regulator, or just curious, and want to compare
stories of what other countries have done to promote IPv6 (as in my
presentation today, https://www.nanog.org/meetings/abstract?id=2486) you can
download the working paper at:
http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2417079

Note that this is a working paper. I appreciate the several offers for more
information on countries where our story is incomplete.

Lee

IPv6 Operations

[Lee Howard]

As a co-chair of the IETF v6ops Working Group, I thought I'd share my notes
about yesterday's meeting with you, as actual operators, and ask for more
input. 
 
Deprecating 6to4
Brian Carpenter discussed draft-ietf-v6ops-6to4-to-historic
http://tools.ietf.org/wg/v6ops/draft-ietf-v6ops-6to4-to-historic/ ,
specifically questions about whether to deprecate it completely, or just the
version based on RFC3068 (which relies on anycast relays), and leave RFC3056
(useful for peer-to-peer kinds of connections) alone. That was the
consensus. Relatedly, there was consensus to recommend filtering the anycast
prefix  192.88.99.0/24, but not the related IPv6 version.


 
Data Center Translation: SIIT-DC
Tore Anderson presented (remotely‹very cool) his idea for statelessly
translating from the IPv4 Internet to an IPv6-only data center. There was
clear consensus that we should continue working on this as a working group,
although it needs a better name, and Tore is looking for co-authors. If you
have data center expertise and have ever wanted your name on an RFC, this is
your chance.  Read draft-anderson-v6ops-siit-dc
http://tools.ietf.org/id/draft-anderson-v6ops-siit-dc-01.txt  and
draft-anderson-v6ops-siit-dc-2xlat
http://tools.ietf.org/id/draft-anderson-v6ops-siit-dc-2xlat-00.txt  and
contact Tore.


DHCPV6/SLAAC Interaction
Bing Liu provided an update on two related documents,
draft-ietf-v6ops-dhcpv6-slaac-problem
http://tools.ietf.org/wg/v6ops/draft-ietf-v6ops-dhcpv6-slaac-problem/  and
draft-liu-v6ops-dhcpv6-slaac-guidance
http://tools.ietf.org/id/draft-liu-v6ops-dhcpv6-slaac-guidance-03.txt .
The discussion focussed on whether the behavior in the presence of both
DHCPv6 and SLAAC is simply ambiguous (and therefore dependent on
implementation) or broken.  If it's ambiguous, we can clarify. If it's
broken, we probably need a specification update (and, in fact, the DHC
working group is working on revising rfc3315). We determined that the
Problem Statement document (which may need to be renamed) should focus on
behaviors in real implementations, and come back to the Guidance document
later.
 
Considerations for Using ULAs
Bing also updated us on draft-ietf-v6ops-ula-usage-recommendations
http://tools.ietf.org/wg/v6ops/draft-ietf-v6ops-ula-usage-recommendations/
, but there was little discussion other than making sure it was consistent
with current work in the Homenet WG.
 
Considerations for Running Multiple IPv6 Prefixes
Sheng Jiang updated us on draft-liu-v6ops-running-multiple-prefixes
http://tools.ietf.org/id/draft-liu-v6ops-running-multiple-prefixes-02.txt
, but it wasn't clear how useful it will be given ongoing work in the MIF
WG, and whether NAT/NPT uses were relevant.  We may revisit it later, if
people want further discussion.
 
IPv6 Vulnerability Test Program in Japan
Ruri Hiromi described the IPv6 vulnerability test program in Japan
https://tools.ietf.org/html/draft-jpcert-ipv6vullnerability-check , and
asked for more participation and support.  This has the potential for being
very useful work; check it out.
  
IPv6 Extension Headers
Fernando Gont detailed his ongoing work on IPv6 Extension Headers in the
Real World 
https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world .  The
authors found that packets with IPv6 EH are often dropped:
€ 20% drop rate for fragments
€ 10% drops for Destination Options
€ 40% drops for Hop-by-Hop options
€ 25% for fragmented traffic
€ 20-60% of drops occur at an AS other than Destination AS
There was general agreement that this was bad, and he described several
ramifications, including DOS vulnerabilities. Fernando said that
applications relying on EH will need a fallback mechanism, but there was
consensus that dropping EH packets is the problem, not the protocol design.
We may work on a document providing recommendations on how to configure.
This seems like a great topic for NANOG members to chime in on; do you drop
packets with Extension Headers, and if so, why?


 
Design Choices for IPv6 Networks
Victor Kuarsingh presented Design Choices for IPv6 Networks
https://tools.ietf.org/html/draft-ietf-v6ops-design-choices , and got
consensus that the title and abstract needed a tighter scope, and the
document should mention a couple of other design alternatives that are
documented in other internet-drafts and RFCs. This document would also
greatly benefit from review from NANOG participants, as it is intended for
this audience.


IPv4 Literals Break in NAT64
Osamu proposed A Special Purpose TLD to resolve IPv4 Address Literal on
DNS64/NAT64 environments
https://tools.ietf.org/html/draft-osamu-v6ops-ipv4-literal-in-url . There
was good discussion, but not consensus that this was the right solution.


Considerations on IPv6-only DNS Development
Linjiang Song talked about Considerations on IPv6-only DNS Development
https://tools.ietf.org/html/draft-song-sunset4-ipv6only-dns . Discussion
focussed on the need for support for EDNS0, 

Re: Belkin Router issues this morning?

[Lee Howard]

On 10/7/14 10:14 PM, Christopher Morrow morrowc.li...@gmail.com wrote:

On Tue, Oct 7, 2014 at 8:56 PM, Larry Sheldon larryshel...@cox.net
wrote:
 I am having trouble understanding why a router would need a heartbeat
from
 some foreign location.  Or even what it would do with one.

One, not crazy, line of thinking is that: Instead of being cryptic
and difficult to understand, help the customer to know that: your dsl
is boarked and that offloading that call set from the ISP for
something that might be simple to fix at the CPE might make the ISP
folk happy.

That would be not-crazy if there were congruence with DSL borked and
host unreachable.


Of course that decision process came with the decision to run a
reliable and always-on service...oops.

Clever!


Lee

Re: NANOG College Immersion Program

[Lee Howard]

I am delighted to see this, and I hope other conferences will do likewise.

Lee

On 9/26/14 10:24 AM, Dave Temkin d...@temk.in wrote:

I'm excited to announce that for NANOG 63 in San Antonio that we will
begin
the NANOG College Immersion Program. This program aims to provide the next
generation of Network Operators with an edge in today's highly competitive
market and allows us a conduit of highly capable operators, engineers, and
architects.

Please see below for the full program description.

Regards,
-Dave Temkin, for the NANOG Board of Directors


NANOG College Immersion Program

Summary:

NANOG is committed to ensuring next generation of networking professionals
have an opportunity become part of the operational community that makes
the
internet run. Companies such as Google, Level 3, Microsoft, NTT, Netflix,
Yahoo, and Amazon rely on NANOG to discuss key architectural and
operational topics relevant to Internet infrastructure. NANOG believes by
introducing undergraduates to our vibrant community before entering the
job
marketplace, they will have a better understanding of how the
infrastructure of the Internet works and how they might participate after
graduation. Further, students may be able to find internship opportunities
they may have not otherwise found.

Offering:

NANOG will provide an expenses-paid trip to the current meeting for up to
25 students per meeting. The paid expenses will include:

   -

   Airfare (up to $500)
   -

   Four nights of hotel (must be booked by NANOG staff)
   -

   Ground transportation (reasonable cost)
   -

   Meal stipend (adjusted for meeting location)



NANOG will also, space permitting, allow free admission for students to
the
NANOG Education Series (https://www.nanog.org/meetings/education/home)
class prior to the meeting they are attending.

NANOG will provide guidance to students as to what they may and may not
attend. Of note, alcohol is served at some NANOG events and there is the
expectation that those not legally entitled to consume alcohol will
refrain
from doing so. NANOG takes no responsibility for those that break the law
during their meetings and reserves the right to refuse admission to those
that violate our Attendance Charter.


Expectation:

NANOG will not be involved in any syllabus or coursework for the students.
The NANOG organization will provide an agenda and slideware for the
materials that the students will be viewing and expects their professor to
determine the best way their students can extract educational value from
the NANOG program. NANOG asks, in return, that all students complete our
surveys in full and that their teaching staff provide us with a summary of
how they used our program in the classroom and/or in coursework. A few
paragraphs from each student explaining the value that they got from the
program and social interactions would also be a good idea.


QA:

Q: What is NANOG and what is the value proposition for sending a student
to
this conference?

A: The North American Network Operators Group or NANOG, is the
professional
association for Internet engineering and architecture. Our core focus is
on
the technologies and systems that make the Internet function: core routing
and switching; Internet inter-domain routing; the domain name system;
peering and interconnection; and Internet core security. We also cover
associated areas with a direct impact on Internet architecture such as
data
centers and optical networking.  The value proposition for the student is
exposure to all of these subjects and technical material but more
importantly to the organizations and individuals.  The opportunity for
students to make industry contacts is invaluable.

Q: How do we select students for this sponsorship?

A: Send your best and brightest, highlight that the value is the density
of
industry representatives in a common location.

Q: What do the students owe back to NANOG?

A: In addition to the anonymous surveys that all attendees are asked to
complete, the NANOG Board would request that all sponsorship recipients
provide feedback on their experiences.  Lastly, we would like to encourage
the students join the mailing list (nanog@nanog.org), attend more
conferences and get involved in the industry.

Q: How do we evaluate our students participation?

A: Students could provide a variety of deliverables back to the
institution.  These could include a writeup of selected presentations from
the agenda, an overview of the conference as a whole, or even a list of
the
individuals they met during the conference.

Q: What will be covered in the sponsorship?

A: Hotel, conference fee, airfare, and a reasonable stipend for
incidentals
such as meals.

Q: Why are you sponsoring our students for this conference?

A: The NANOG organization is keen to encourage the future technology
leaders and innovators to get interested and involved in this segment of
the industry.

Re: Carrier Grade NAT

[Lee Howard]

On 7/30/14 3:45 PM, joshua rayburn jbrayb...@gmail.com wrote:


Starting in 3.10 code you can utilize Bulk Port Allocation to carve out
small consecutive port bundles for end users as to not mess up SIP
functionsand High Speed Logging to log individual customers ports for law
enforcement needs without overrunning your logging server.


http://tools.ietf.org/html/rfc6056 documents a security concern with bulk
port assignments.

Lee

Re: Carrier Grade NAT

[Lee Howard]

On 7/29/14 1:00 PM, Robert Drake rdr...@direcpath.com wrote:


On 7/29/2014 12:42 PM, Chris Boyd wrote:

 There's probably going to be some interesting legal fallout from that
practice.  As an ISP customer, I'd be furious to find out that my
communications had been intercepted due to the bad behavior of another
user.

 --Chris

Usually, unless the judge is being super generous, they'll provide a
timestamp and a destination IP.  That should be pretty unique unless
they're looking for fraud against large website or something.  In the
unlikely event that two people hit the same IP at the same time(window)
they would probably just throw that information out as unusable for
their case.

If your CGN logs destination IP, then you are tracking every site your
customer visits.  Geoff posits that this is valuable information, but some
of the likeliest buyers aren't interested.  You'll want to find some
buyers, because you'll need to defray the cost of your logging. Do some
back-of-the-envelope math on the storage required per user per day if you
log the 5-tuple.

The alternative is logging of address and source ports only, keeping logs
equivalent to your DHCP logs now.

I've also heard law enforcement say they're not necessarily keen to ask,
Which of your customers accessed this web site at this time?  Sometimes
it's awkward.  They're much more likely to say, Who was using this
address (and source port) at this time?

If they can't tell you the source port, you have two options:
1. Give them the names of all customers using that address at that time.
How many--10? 50? 100?
2. Tell them their subpoena is too broad, and you cannot respond.

I suggest you consult with counsel to determine your response.

Lee

Re: Carrier Grade NAT

[Lee Howard]

Thanks for sharing your experience; it's very unusual to get the
perspective of an operator running CGN (on a broadband ISP; wireless has
always had it).

On 7/29/14 5:28 PM, Tony Wicks t...@wicks.co.nz wrote:

OK, as someone with experience running CGNAT to fixed broadband customers
in
general, here are a few answers to common questions. This is based on the
setup I use which is CGNAT is done on the BNG (Cisco ASR1K6).

1. APNIC ran out of IPv4 a couple of years ago, so unless you want to pay
USD $10+ per IP then CGNAT is the only option.

Eh, a bit over US$7 now, but whatever. Higher in APNIC.

2. IPv6 is nice (dual stack) but the internet without IPv4 is not a viable
thing, perhaps one day, but certainly not today (I really hate clueless
people who shout to the hills that IPv6 is the solution for today's
internet access)

It's viable, it's just not a substitute for IPv4 yet.
Except for specific scenarios.  For instance, you mention gaming below; if
two users are playing on Xbox ONE, they can use IPv6 and they're off the
CGN.  Or if a bank has blacklisted an IPv4 address on the CGN, but the
bank is dual-stack, some users can still get there.
Of course, that snowballs.

3. 99.99% of customers don't notice they are transiting CGNAT, it just
works.

Surprised it's that high.

4. You need to log NAT translations for LI purposes. (IP
source/destination,
Port source/destination, time) Surprisingly this does not produce that
big a
database burden. However as Cisco's Netflow NAT logging is utterly useless
you need to use syslog and this ramps up the ASR CPU a bit.

Can you quantify?
The log entry has to be at least:
32 bits source address
16 bits source port
32 bits destination address
16 bits destination port
64 bits? timestamp
---
160 bits = 20 bytes per flow
You have to log the end of the flow, too, right?  Another 20 bytes?
40 bytes per flow.  Not including syslog severity and message text.

As I recall, a site like cnn.com opens 80 flows, so 3200 bytes of log data.
If, as you say in #6, 10,000 customers = 200,000 active translations,
that's 8,000,000 bytes of syslog. . . per second?  Not sure if active
indicates how fast those sessions churn.
180 days of log retention would be. . . 124TB of data.  Per 10,000 users.

By the way, if that's 8MB of syslog, that's 32Mbps just of logging data.
Average, not peak.

Maybe the actual log rate is 8MB per five minutes?  That's only 400GB for
six months.

I'm really interested in what your actual log rate is.


5. NAT translation timeouts are important, XBOX and PlayStation suck.

At least Xbox ONE prefers IPv6.
PS4 can, it just doesn't yet.
Maybe Kiwis don't play enough games for Sony to care?

6. 10,000 customers= approximately  200,000 active translations and 1-2
/24's to be comfortable

So you've cut your address expense to US$0.50 per user.  Definitely better.
(500*$10/1)

7. CGNAT protects your customers from all sorts of nasty's like small DDOS
attacks and attacks on their crappy CPE
8. DDOS on CGNAT pool IP's are a pain in the rear and happen often.

Between #7 and #8, do they balance out?

9. In New Zealand we are not a state of the USA so spammed DCMA emails can
be redirected to /dev/null. If a rights holder wishes to have a potential
violation investigated (translation logs) they need to pay a $25 fee, so
in
general they don't bother. Police need a search warrant so they generally
only ask for user info when they actually can justify it, so it's not a
big
overhead.

As long as you have a tool to query your logging system, should be fine.

10. It is not uncommon for people who run some game servers and websites
(like banks) to be completely clueless/confused about cgnat and randomly
block IP's as large numbers of users connect from  single IP. This is not
a
big issue in practice.

Really?  Seems like those would be some of the loudest users.

I've always suggested adding IPv6 as an outlet, so that if someone
complains about something not working through CGN, you can tell them to
deploy IPv6.  

Thanks again for this perspective.

Lee

Re: Canada and IPv6 (was: Ars Technica on IPv4 exhaustion)

[Lee Howard]

I notice an IETF meeting in Toronto one month hence.
If Canadian operators (and content providers) were interested in talking
about their common problems, it might be convenient to schedule some time
adjacent to that meeting.

Lee

On 6/20/14 10:12 AM, jean-francois.d...@videotron.com
jean-francois.d...@videotron.com wrote:

Videotron (AS5769) is offering 6RD (RFC5969) to all residential
customers, 
if their gear supports it. (DHCP option 212)

(But our MGMT still calls it beta for now.)

JF

Jean-François Dubé
Technicien, Opérations Réseau IP
Ingénierie Exploitation des Réseaux
Vidéotron

NANOG nanog-boun...@nanog.org a écrit sur 2014-06-18 20:16:01 :

 De : Sadiq Saif li...@sadiqs.com
 A : nanog@nanog.org,
 Date : 2014-06-19 12:43
 Objet : Canada and IPv6 (was: Ars Technica on IPv4 exhaustion)
 Envoyé par : NANOG nanog-boun...@nanog.org
 
 On 6/18/2014 14:25, Lee Howard wrote:
  Canada is way behind, just 0.4% deployment.
 
 Any Canadian ISP folk in here want to shine a light on this dearth of
 residential IPv6 connectivity?
 
 Is there any progress being made on this front?
 
 -- 
 Sadiq Saif

Re: Ars Technica on IPv4 exhaustion

[Lee Howard]

On 6/19/14 11:13 PM, Christopher Morrow morrowc.li...@gmail.com wrote:

On Thu, Jun 19, 2014 at 5:24 PM, Lee Howard l...@asgard.org wrote:


 On 6/19/14 4:30 PM, Christopher Morrow morrowc.li...@gmail.com
wrote:

So, I was focusing on the end-user (Consumer) set because given enough
migration there that should push more application folk in the right
direction.

Why?
Some content providers have said that they think IPv4 runout is an ISP
problem.
As long as users have IPv4, there's no reason for them to move.
What percentage of eyeballs would need to be dual-stack for app folk to
decide to support IPv6?


I think ipv6 still suffers from the chicken/egg problem:
  1) users aren't asking so isps aren't selling/doing
  1b) ISPs still ahve v4 or a solution (they think) to no-more-v4 and
can keep rolling new customers out

I simply don't think this is the case anymore, at least in the U.S.  IPv6
deployment to users is huge, and will automatically snowball as old CPE
cycles out.  Mid-sized operators will be coming up this year.  Half of
mobile is done.
I don't know of any U.S. ISP or wireless carrier that is planning to use
the address market or CGN as their exhaustion strategy.


  2) content places have no one they can't reach today because there's
v4 to everyone that they care about
  3) both sides still playing chicken.

oh well, see you on this same conversation in another 18 months time?

I've said this several times, so for the record, here's my prediction:
After ARIN runs out, and it may be 1-3 years after ARIN runs out, ISPs
will incur the rising costs of IPv4 (through CGN or the address market).
Eventually, costs will be so high that they offer IPv6 at a lower price,
either for paid peering or to consumers.  At that point, content providers
will have a financial reason to migrate, and will painfully find that by
the time they can do so, they will have already lost the users.

To be clear, some content providers support IPv6, and some ISPs support
IPv6.  It's everybody else we need to move. And until they do, the
Internet will be more expensive, or fragmented, or both.

Also for the record: My prediction does not reflect any knowledge of any
specific company's plan.

Lee

Re: Ars Technica on IPv4 exhaustion

[Lee Howard]

On 6/17/14 11:43 PM, Frank Bulk frnk...@iname.com wrote:

These sites used to be dual-stacked:
www.cablelabs.com (over 180 days ago via ipv6.cablelabs.com)
www.att.net (over 44 days ago)
www.charter.com (over 151 days)
www.globalcrossing.com (over 802 days)
www.timewarnercable.com (over 593 days)

Check that one again.

Surprised you didn't mention www.bing.com.

Lee

Re: Ars Technica on IPv4 exhaustion

[Lee Howard]

 I support a recommendation to consumer retailers to start requiring IPv6
 support in the stuff that they sell, but unfortunately I don¹t have very
 good data on how large of a request that actually is.

In my experience, retailers will sell whatever flies off the shelves
without
regard to whether it¹s good for the consumer or not. As such, I believe
it¹s
more of a consumer education issue if we want to effect real change in
behavior
at this point.

What would you tell consumers?

Lee


Owen

Re: Ars Technica on IPv4 exhaustion

[Lee Howard]

On 6/18/14 7:26 PM, Karl Auer ka...@biplane.com.au wrote:

On Wed, 2014-06-18 at 19:02 -0400, George, Wes wrote:
 Similarly, Belkin¹s home routers appear to support IPv6, but that
doesn¹t
 appear in the specs or features list on their site when I just checked
it.

There's also an issue of what IPv6 support actually means. A few years
ago it meant has IPv6 printed on the box :-) Now it means - what?


For gateways, the IPv6 CE Router is the spec to seek.
For other electronics, the CEA is working on a spec, keep an eye out.
 
Lee

Re: Ars Technica on IPv4 exhaustion

[Lee Howard]

From:  Brian Hartsfield b...@tronstar.com
Date:  Thursday, June 19, 2014 11:27 AM
To:  Lee Howard l...@asgard.org
Cc:  Owen DeLong o...@delong.com, Wesley George
wesley.geo...@twcable.com, nanog@nanog.org nanog@nanog.org
Subject:  Re: Ars Technica on IPv4 exhaustion

 For consumers I think I would phrase it more as the next generation internet
 and you need IPv6 in order to be able to connect to it and that eventually
 some sites you want to connect to may not be accessible over the current
 internet. Something like that.

Ah, it's running Internet-As-A-Service in the Cloud using a Client-Server
architecture with time sharing.  There's nothing there but buzzwords.

First figure out what consumers actually get for it.  Only after you know
why they want it can you then figure out how to market it.  Generally what
you're looking for is good, fast, cheap, only more so than IPv4.


Lee

 
 I am going to be real interested to see how the media handles the situation
 when ARIN runs out of IPv4 addresses.   I could really see some big doom and
 gloom stories hit some of the mainstream media when that occurs.  While it
 isn't the end of the world when ARIN runs out, it is still significant and I
 personally think that moment is going to be what starts to spur more CIOs to
 start asking questions about IPv6 and if their organization is ready (and the
 answer likely being no)
 
 --
 Brian Hartsfield  CCNA, CCDA
 AIM: kd4aej Twitter: Krandor1
 Facebook: http://www.facebook.com/brian.hartsfield
 Linkedin: http://www.linkedin.com/in/brianhartsfield
 
 
 On Thu, Jun 19, 2014 at 10:02 AM, Lee Howard l...@asgard.org wrote:
 
 
 
  I support a recommendation to consumer retailers to start requiring IPv6
  support in the stuff that they sell, but unfortunately I don¹t have very
  good data on how large of a request that actually is.
 
 In my experience, retailers will sell whatever flies off the shelves
 without
 regard to whether it¹s good for the consumer or not. As such, I believe
 it¹s
 more of a consumer education issue if we want to effect real change in
 behavior
 at this point.
 
 What would you tell consumers?
 
 Lee
 
 
 Owen
 
 
 
 
 
 

Re: Ars Technica on IPv4 exhaustion

[Lee Howard]

On 6/19/14 2:50 PM, Christopher Morrow morrowc.li...@gmail.com wrote:

On Thu, Jun 19, 2014 at 2:32 PM, Edward Arthurs
earth...@legacyinmate.com wrote:
 You are correct, but this is the tip of the iceberg as other
configurations will need to come into play as pointed out by several
people on this thread.
 This learning curve is not impossible, if the net admin really applies
his/her self to learning it.


I'd still say that for uptake across the board the mid/small business
(and even large business) isn't relevant. The numbers of these are so
small as to be insignificant to the problem.

Solving the problem for end-users seems like where ISP folk should
spend their time, and really it's in their best interest to do that so
they can keep expanding their customer base as ipv4 resources become
less available in their networks and globally.

How does IPv6 to end users make IPv4 unnecessary for growth, if
enterprises and content providers haven't deployed IPv6?

Lee

Re: Ars Technica on IPv4 exhaustion

[Lee Howard]

On 6/19/14 4:30 PM, Christopher Morrow morrowc.li...@gmail.com wrote:

On Thu, Jun 19, 2014 at 4:27 PM, Lee Howard l...@asgard.org wrote:

 How does IPv6 to end users make IPv4 unnecessary for growth, if
 enterprises and content providers haven't deployed IPv6?

content folk are mostly getting v6 done already, right? (minus AWS/etc
which are on-plan to deploy as near as I can tell)
I don't think enterprise folk matter here, they'll get to v6 when they
have enough problems related to v4 content reachability... and when
they try the ISP network ought to be prepared to deal with them.


7.94% Google hits in the U.S. come from IPv6 addresses.

http://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-ad
option
7.29% of web sites have a working .
http://www.employees.org/~dwing/-stats/




which content providers (large-ish ones) are lagging still?

https://www.vyncke.org/ipv6status/detailed.php?country=us

Microsoft: live.com, Bing, MSN, microsoft.com
Twitter
Amazon
LinkedIn
WordPress
eBay, PayPal
Pinterest
Instagram
Ask.com
Tumblr
IMDB
Craigs List
Imgur
Reddit
CNN
Disney, Go, ESPN
GoDaddy
HuffPo
WordPress
Adobe
Vimeo
Flickr
Dropbox
CNet
BuzzFeed
NYTimes
Most porn sites (one has a dead ).
The web site of any TV channel, or any bank.
Not to mention the million web pages at hosting providers.
 

Lee

Re: Ars Technica on IPv4 exhaustion

[Lee Howard]

On 6/19/14 5:02 PM, John Curran jcur...@arin.net wrote:

On Jun 19, 2014, at 4:27 PM, Ricky Beam jfb...@gmail.com wrote:

 On Thu, 19 Jun 2014 14:35:55 -0400, John Curran jcur...@arin.net
wrote:
  Any suggestions on how ARIN should reach those CIO's in the meantime?
 
 Refuse additional IPv4 assignments to those who have not deployed IPv6.
And not just been assigned a v6 block, but actually running IPv6 to
every customer who asks. (hard to police, sure.)
 ...

Ricky - 
  
   You should consider submitting this as policy proposal
   https://www.arin.net/policy/pdp_appendix_b.html


I support the idea of new policy proposals, but by the time this made it
through a policy cycle, ARIN would have run out of unallocated IPv4
addresses.  A similar constraint could be applied to recipients of IPv4
transfers; the community would want to consider that very carefully.

Would there be a similar constraint for CDNs, hosting companies, and cloud
providers?

btw, Ricky, if you want support in getting your proposal submitted, John
will team you up with somebody on the superlative Advisory Council
https://www.arin.net/about_us/ac.html, many of whom are watching this list.

Lee

Re: Ars Technica on IPv4 exhaustion

[Lee Howard]

On 6/17/14 6:12 PM, Andrew Fried andrew.fr...@gmail.com wrote:

IPv6 will never become the defacto standard until the vast majority of
users have access to IPv6 connectivity.

How many users have access to IPv6 connectivity?

Since this is NANOG, let's talk about North America.

Canada is way behind, just 0.4% deployment.
The U.S. is one of the top countries, in both number of users and number
of top web sites.
Three of the big four U.S. ISPs have double-digit deployment. It's not the
vast majority yet, because:
1. Older modems don't support IPv6 (older than, what, 2008?).  As those
churn, counts will rise.
2. Older gateways, especially consumer-owned retail devices, don't support
IPv6.  Churn would help, if new retail gateways supported IPv6.
3. The 10% of people with MacOS use IPv6 half the time (more or less)
that it's available.

I can't find statements right now, but I think those big three are all
90% deployed, if you don't count rolling trucks to replace modems.  The
number of IPv6-capable users is several times higher than the number of
people actually using IPv6, and I don't know why.

Verizon Wireless and T-Mobile have great IPv6 deployments, too, maybe a
couple more years for older handsets to age out.  Still, 50% of VzW LTE
devices use IPv6 now.



Everything I have at the colo is dual stacked, but I can't reach my own
systems via IPv6 because my business class Verizon Fios connection is
IPv4 *only*. 

Well there's your problem.


 Yes, Comcast is in the process of rolling out IPv6, but my
Comcast circuit in Washington DC is IPv4 only.  And I'd suspect that
everyone with Time Warner, ATT, Cox, etc are all in the same boat.

I think all of those companies offer IPv6 on their business-only services
(e.g., fiber, ethernet, etc.). For access methods shared with residential
users (i.e., DOCSIS, DSL), it's not rolled out yet. . . RSN.


Whether the reason for the lack of IPv6 deployment is laziness or an
intentional omission on the part of large ISPs to protect their income
from leasing IPv4 addresses

ISPs want to protect their income by continuing to turn up services.

Lee

Andrew Fried
andrew.fr...@gmail.com

On 6/17/14, 5:48 PM, Jared Mauch wrote:
 
 On Jun 17, 2014, at 5:41 PM, Lee Howard l...@asgard.org wrote:
 


 On 6/17/14 4:20 PM, Jay Ashworth j...@baylink.com wrote:

 Here's what the general public is hearing:

 But only while they still have IPv4 addresses:
 ~$ dig  arstechnica.com +short
 ~$ 





 
http://arstechnica.com/information-technology/2014/06/with-the-americas
-ru
 nning-out-of-ipv4-its-official-the-internet-is-full/


 Can't tech news sites *please* run dual stack while they're spouting
 end-of-IPv4 stories?
 
 wishful thinking=on
 
 I would love to see a few more properties do IPv6 by default, such as
ARS, Twitter and a few others.  After posting some links and being a log
stalker last night the first 3 hits from non-bots were from users on
IPv6 enabled networks.
 
 It does ring a bit hollow that these sites haven't gotten there when
others (Google, Facebook) have already shown you can publish 
records with no adverse public impact.  Making IPv6 available by default
for users would be an excellent step.  People like ATT who control the
'attwifi' ssid could do NAT66 at their sites and provide similar service
to the masses.  With chains like Hilton, McDonalds, etc.. all having
this available, it would push IPv6 very far almost immediately with no
adverse impact compared to users IPv4 experience.
 
 - Jared
 

Re: Credit to Digital Ocean for ipv6 offering

[Lee Howard]

On 6/18/14 2:44 PM, John R. Levine jo...@iecc.com wrote:

 I find the /50 particularly odd as it's not a nibble boundary and very
 close to /48. It's almost certain this is an operator who fails to
grasp 
 that they could have easily gotten a larger allocation from their RIR
if 
 they just asked for it and provided the appropriate justification in
 terms of giving /48s to their customers. OTOH, it's far better than
 those ridiculous providers that are screwing over their customers with
 /56s or even worse, /60s.

It's Time-Warner, and they are not ignorant.  I think they're
experimenting.  They are still working out bugs in their internal
routing, 
since my v6 routes have an annoying habit of disappearing inside their
network if I don't do a ping that passes through them every couple of
minutes.

Also, it may not actuallly be a /50.  That's what their rwhois says, but
I haven't done a tcpdump so I don't know what size they're actually
offering me.

It's either a /64 or a /56 or a misconfiguration.

Lee

Re: Ars Technica on IPv4 exhaustion

[Lee Howard]

On 6/18/14 3:38 PM, Owen DeLong o...@delong.com wrote:


 2. Older gateways, especially consumer-owned retail devices, don't
support
 IPv6.  Churn would help, if new retail gateways supported IPv6.

Several do now. What are $CABLECO, $CE_STORES, etc. doing to make sure
consumers choose these or at least realize the consequences of failing to
choose them?

http://www.timewarnercable.com/en/residential-home/support/topics/internet/
buy-your-modem.html
http://mydeviceinfo.comcast.net/
http://www.businesswire.com/news/home/20140107006526/en/CEA-Selects-Safe-Dr
iving-IPv6-Implementation-Standards#.U6HuqS_9q_s


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

Re: Ars Technica on IPv4 exhaustion

[Lee Howard]

On 6/17/14 4:20 PM, Jay Ashworth j...@baylink.com wrote:

Here's what the general public is hearing:

But only while they still have IPv4 addresses:
~$ dig  arstechnica.com +short
~$ 




  
http://arstechnica.com/information-technology/2014/06/with-the-americas-ru
nning-out-of-ipv4-its-official-the-internet-is-full/


Can't tech news sites *please* run dual stack while they're spouting
end-of-IPv4 stories?

Lee

Re: Time Warner IPv6 Reverse DNS?

[Lee Howard]

We've corresponded offline.

I documented the difficulties in providing reverse DNS for IPv6
residential users in http://tools.ietf.org/html/draft-howard-isp-ip6rdns-06
It's a long-expired draft, which never found sufficient support from a WG
or AD.  I've been meaning to rewrap it as a BCOP, but lack cycles.

Lee

On 6/12/14 11:58 AM, hasser css hasserva...@gmail.com wrote:

Some IPv6 email is not working well for me on my TWC Internet connection
due to their IPv6 block not having PTR records.

Is it possible for me to delegate my IPv6 range to my own DNS server, or
something similar? I have talked to level 3 support and they were pretty
much clueless, so I decide to ask here if anyone has insight or similar
issues in the past.

Thanks!

Re: IPv6 at 50% for VZW (Re: NAT IP and Google)

[Lee Howard]

On 5/22/14 9:41 PM, Martin Hannigan hanni...@gmail.com wrote:


My job isn't to increase v6. It's to make sure we can serve traffic over
protocols we are asked to. We are dual stacked which means our customers
are.

I'm not going to tell you what your job is.
I'm curious, though, whether your customers specify the Internet Protocol,
and if so, whether they specify a version number?  As we say in rfc6540,
you should be certain you know whether an implementation is inclusive or
exclusive of IPv6.

Lee

Re: IPv6 at 50% for VZW (Re: NAT IP and Google)

[Lee Howard]

On 5/22/14 8:04 AM, Livingood, Jason jason_living...@cable.comcast.com
wrote:

On 5/21/14, 9:38 PM, Jared Mauch ja...@puck.nether.net wrote:

On May 21, 2014, at 7:17 PM, Ca By cb.li...@gmail.com wrote:

 Verizon Wireless is at 50% ipv6 penetration

I suspect this would go up significantly if Twitter and Instagram would
IPv6 enable their services.  Same for pintarest.

+1
We naturally focus a lot on network enablement here, but IMO it is a great
time to focus on more web-based services embracing IPv6 with another June
6 just around the corner. :-)

A side project I've been meaning to take on:

In his really useful listing of content providers' IPv6 support,
https://www.vyncke.org/ipv6status/  Eric Vyncke has added CDN to sites
using an identifiable CDN.
I've been meaning to write a script to pull those sites and CDNs, to
identify bang for the buck in CDN enablement.  I know Akamai is
enormous, but if CloudFlare, Limelight, and a couple of hosting companies
were to dual-stack all of their customers, would it matter that Akamai and
Amazon weren't doing so yet?  Or another way to look at it would be, who
would be the key players for a major content enablement day?

Lee

Re: Requirements for IPv6 Firewalls

[Lee Howard]

On 4/18/14 10:16 PM, Matt Palmer mpal...@hezmatt.org wrote:

On Fri, Apr 18, 2014 at 10:04:35PM -0400, Jeff Kell wrote:
 As to address the other argument in this threat on NAT / private
 addressing, PCI requirement 1.3.8 pretty much requires RFC1918
addressing
 of the computers in scope...  has anyone hinted at PCI for IPv6?

1.3.8 lists use of RFC1918 address space as one of four possible
implementations, immediately after the phrase may include, but are not
limited to.  I don't interpret that as pretty much requires RFC1918.

It's not clear whether those are alternatives or should all be employed.
An auditor will tend to recommend all of them.


Now, if you'd like to claim that 1.3.8 is completely useless, I won't
argue
with you -- it's security-by-obscurity of the worst possible form.  But
don't blame PCI compliance for any inability to deploy IPv6, because it
just
ain't true.


Methods used to meet the intent of this
requirement may vary depending on the specific
networking technology being used. For example,
the controls used to meet this requirement may be
different for IPv4 networks than for IPv6 networks.
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf

Based on my experience with compliance auditors, they won't understand
many of the words in this sentence, and will assume NAT and RFC1918.  They
can often (but not always) be taught, but you have to take the time to
explain how IPv6 works, and how you prevent a reconnaissance attack. Many
enterprise network administrators are not up to this task, unfortunately.

ULA + NPT66 should be pretty easy to explain, both technically, and as a
method of demonstrating compliance.  However, preventing outbound route
leaks of more-specifics, and blocking inbound recon attacks/probes
*should* be equally compliant.

Lee

Re: Requirements for IPv6 Firewalls

[Lee Howard]

From:  George Herbert george.herb...@gmail.com
Date:  Friday, April 18, 2014 7:11 PM
To:  Lee Howard l...@asgard.org
Cc:  Eugeniu Patrascu eu...@imacandi.net,
draft-gont-opsec-ipv6-firewall-r...@tools.ietf.org
draft-gont-opsec-ipv6-firewall-r...@tools.ietf.org, nanog@nanog.org
nanog@nanog.org
Subject:  Re: Requirements for IPv6 Firewalls

 Lee Howard:
 So, yeah, you have to give your firewall administrator time to walk
 through the rules and figure out what they ought to be in IPv6.  Your
 firewall administrator has been wanting to clean up the rules for the last
 two years, anyway.
 
 
 The arrogance in this assertion is amazing.

What arrogance?  I think I assert that IPv6 is time-consuming.
There is no deploy IPv6 button.

fwiw, I do have enterprise network experience.

 
 You're describing best practice.  Yes, of course, you should have well
 documented technical and business needs for what's open and what's closed in
 firewalls, and should have traceability from the rules in place to the
 requirements, and be able to walk the rules and understand them and
 reinterpret them from v4 to v6, to a new firewall vendor, etc etc.

Yes.  Any publicly-traded company will have this because their auditors
require it.  
I would think that companies without this documentation are probably not
ready to deploy a new protocol.
I concede that tracing the rules to the requirements is a hard one in
practice (and a PITA in operational practice), but I don't think it's
required to be able to map IPv4 rules to IPv6 rules.

 
 Again - THE INERTIA IN REAL ENTERPRISE ENVIRONMENTS SAYS OTHERWISE.

To clarify: are you asserting that IPv6 uptake in enterprises is slow, which
is a sign of inertia, and the reason is that firewalls are poorly documented
and therefore we must have IPv6 NAT?
Maybe lack of (perceived) business need is the reason more enterprises
don't have IPv6.

Š

 
 Again - policy community blinders on understanding what real systems are like
 out in the world has repeatedly shot the conversion in the legs.  If you're
 going to start floating standards for this kind of stuff, then listen to
 feedback on why things are failing.

I don't agree that things are failing.
I would absolutely like to see enterprises adopt IPv6.  Maybe at this stage
enterprises with no firewall documentation are not good candidates for
dual-stack.  Those do seem to me to be the kind of clients who are likely to
blame IPv6 for any problem, and insist it be turned off before any other
troubleshooting.

Lee

Re: Requirements for IPv6 Firewalls

[Lee Howard]

On 4/17/14 8:51 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.


http://datatracker.ietf.org/doc/rfc6879/

This document analyzes events that cause renumbering and describes
   the current renumbering methods.  These are described in three
   categories: those applicable during network design, those applicable
   during preparation for renumbering, and those applicable during the
   renumbering operation.


Lee


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

[Lee Howard]

On 4/17/14 11:51 AM, William Herrin b...@herrin.us 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.

You've said this before, and it is still an absurdly over-broad statement.
Many security professionals have deployed enterprise firewalls to their
satisfaction without NAT-PT.

We had this debate, what, a month ago?  Your position hasn't changed.  No
new use cases have emerged.  Are we done here?

Lee

Re: Requirements for IPv6 Firewalls

[Lee Howard]

On 4/17/14 4:45 PM, George Herbert george.herb...@gmail.com wrote:

 There's a fair argument to be made which says that kind of NAT is
  unhealthy. If its proponents are correct, they'll win that argument
  later on with NAT-incompatible technology that enterprises want. After
  all, enterprise security folk didn't want the Internet in the
  corporate network at all, but having a web browser on every desk is
  just too darn useful. Where they won't win that argument is in the
  stretch of maximum risk for the enterprise security folk.
 
 
 Any technology has associated risks, it's a matter of how you
 reduce/mitigate them.
 This paranoia thingie about IPv6 is getting a bit old.
 Just because you don't (seem to) understand how it works, it doesn't
mean
 no one else should use it.



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.

What you are failing is that redesign firewall rules and approach from
scratch along with the IPv6 implementation usually is not the chosen
path,
versus re-implement the same v4 firewall rules and technologies in IPv6
for the IPv6 implementation, because all the IPv6 aware net admins are
having too much to do dealing with all the other conversion issues, vendor
readiness all across the stack, etc.

One of the things we (operator hat) like about IPv6 is that we get to
clean up the mess we made in IPv4. In many cases we've significantly
reduced the number of firewall rules or ACL lines, because we don't have
disaggregate blocks we have to stack up.

On my enterprise firewalls, I had a couple of DMZs, a couple of internal
networks, and policies for what could get where.  Firewalls referred to
objects of various kinds, some of which had multiple addresses listed;
putting servers with similar policies in a single /64 (or a /60 if I
needed separate VLANs) would have simplified things.  And the policy/rule
difference between net 10 addresses internally and GUA prefixes internally
is null.

So, yeah, you have to give your firewall administrator time to walk
through the rules and figure out what they ought to be in IPv6.  Your
firewall administrator has been wanting to clean up the rules for the last
two years, anyway. 

Even if the above doesn't apply to you, what rules do you have that you
can't copy?
* deny ICMP to any.  Can't do that.  Must allow at least some messages.
* deny (public address range) to (private address range) unless initiated
form inside.  Substitute external and internal prefixes.
* deny (outside) to (DMZ) except (port ranges).  Same in IPv6.
* deny (inside) to (DMZ) except (port ranges).  Same in IPv6.

As I recall, the rules were in place even when we used NAT.  If no
thinking required firewall administration is your goal, I'm not clear how
this interferes.



Variations on this theme are part of why it's 2014 and IPv6 hasn't already
taken over the world.  The more rabid IPv6 proponents have in fact shot
the
transition in the legs repeatedly, and those of us who have been on the
front lines would like you all to please shut up and get out of the way so
we can actually finish effecting v6 deployment and move on to mopping up
things like NAT later.

This is why listening to operators is important.

Some operators want NAT.  Some don't.  There are loud voices on both
sides. Consensus seems slightly against.
However, ULA + NPT works.

Lee

Re: Requirements for IPv6 Firewalls

[Lee Howard]

On 4/18/14 4:33 PM, George Herbert george.herb...@gmail.com wrote:

If William and I fight that fight, lose it, and come back and tell you
They won't go because insufficient NAT you need to listen.  I've fought
this in a dozen places and lost 8 of them, not because I don't know v6,
but
because the clients have inertia and politics around security posture
changes (and in some cases, PCI compliance regs).


IPv6 evangelists are used to fighting inertia.
PCI, however. . . anyone have any contacts there?

Lee

Re: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal)

[Lee Howard]

On 3/27/14 6:42 PM, Randy Bush ra...@psg.com wrote:

nanog is a separable game.  it is currently very confused between form
and substance, making committees for everything.  like the bcop thing.
two organizations, nanog and isoc, forming organizational structures to
create a document store.  the ops' doc store is ripe's because the ripe
wgs produced work and someone realized they needed a place to stash it.

I like this example, but not sure how it could apply here.  Need a NANOG
document series?  It wouldn't be an ARIN document series, would it?  Or
did I miss the point of your example?




i purposefully phrased it a bit differently, how can arin engage, get
real participation from, and serve its community, the operators.  i was
stealing examples from ripe.

but, for concrete action, how about a half day session at the next nanog
meeting on, for example, arin database services, whois and irr.  not to
try to reach hard conclusions or plans.  but to open a dialog to explore
what the community gets and wants from these services and how they are
provided.

I like this example.
I also appreciate the policy hour, where NANOG attendees get a few minutes
on ARIN proposals. 

In another message you complimented the RIPE Atlas project. I like the
work from APNIC's labs, too.  I also like LACNIC's development projects,
FRIDA, +RAICES, and education efforts. Would these kinds of efforts be in
scope for ARIN?  Does ARIN need a Chief Scientist (a la Karrenberg or
Huston)? Or is that a NANOG role, since it might include things outside of
management of number resources?

I think North American operators are missing some advantages of the
closely coordinated RIR/NOG operations in other regions, and I would like
to see them closer together here.  Unfortunately, it is not clear to me
that the examples above are in charter for either NANOG or ARIN. I'd be
happy to re-charter either, but that's probably a topic for NANOG-futures.



or pick another key service.

DNS?  DNSsec?
Security?





randy

Lee

Re: misunderstanding scale

[Lee Howard]

On 3/24/14 2:38 PM, William Herrin b...@herrin.us wrote:

On Mon, Mar 24, 2014 at 2:23 PM, Lee Howard l...@asgard.org wrote:
 On 3/24/14 1:37 PM, William Herrin b...@herrin.us wrote:
That would be one of those details on which smart people disagree.
In this case, I think you're wrong. Modern NAT superseded the
transparent proxies and bastion hosts of the '90s because it does the
same security job a little more smoothly. And proxies WERE designed to
act as a security feature.

 What kinds of devices are we talking about here?  Are we talking about
the
 default NAT on a home network router, or an enterprise-level NAT
operating
 on a firewall?

Hi Lee,

I don't see NAT as a deployment issue for residential networks. Most
folks just hook their computer up to whatever CPE the vendor sends
them without any further attention.


 If we're talking about an enterprise firewall, then I don't
 understand--we're talking about a firewall.  If it implements a
symmetric
 NAT in addition to a stateful firewall, then it's implementing the same
 function twice.  But, hey, it's your network, if
 security-through-obscurity is one of your defense in depth layers,
that's
 fine.

Obscurity offers one or more defense layers. If you disagree, post
your passwords here.

One that is largely mocked by security professionals.  However, ULA can do
this.


Unaddressibility is a second defense layer.

I offered ULA+NPT66.  I don't recommend it, but it has been described as
working, and provides addresses which are not globally reachable.


Stateful firewalling is a third.

We agree.

Lee

Re: IPv6 Security [Was: Re: misunderstanding scale]

[Lee Howard]

On 3/24/14 10:17 PM, Naslund, Steve snasl...@medline.com wrote:

I can easily answer that one as a holder of v4 space at a commercial
entity.  The end user does not feel any compelling reason to move to ipv6
if they have enough v4 space.

I can't give my employer a solid business case of why they need to make
the IPv6 transition.

You may not need to yet.  But it would be a good idea to know how long it
would take you to deploy IPv6.
Then think about when IPv6 will be cheaper than IPv4.
(See the poll from NANOG60 for what others think about this:
http://www.wleecoyote.com/blog/lightningpoll.htm
Hint: 2017-2018)
It might be a good idea to finish in time to save money.

Oh, and if the enterprise cares about latency, IPv6 is better.  (NANOG60:
https://www.nanog.org/meetings/abstract?id=2281)



They already hold enough v4 space and are putting more and more servers
behind virtual IPs on boxes like the F5 so they are actually gaining on
the v4 space issue.  They see no economic reason to add an additional
layer of complexity to their network where it is already pretty expensive
to find savvy staff.  Having to find v6 savvy staff is even more
challenging.  Even if the network guys are up to speed on v6 (admittedly
a lot of the junior guys are not) the server and storage guys have a hard
time wrapping their minds completely around ipv4.

I bet your staff isn't savvy on lots of things they have to do.  I don't
know why IPv6 scares people so much.
Story: 
So, will you be providing training on IS-IS?
You'll get exactly the same training you got on OSPF when you started.
. . .

Lee

Re: misunderstanding scale (was: Ipv4 end, its fake.)

[Lee Howard]

On 3/24/14 9:12 PM, Bob Evans b...@fiberinternetcenter.com wrote:


I agree with one thing herein

 In order for IPv6 to truly work, everyone needs to be moving towards
IPv6.

Yep, chicken and the egg. I agree. We built an IPv6 native network - no
tunneling - no customers to speak of ... didn't even bother to start IPv6
peering on it.

How would there be traffic if you have no peering?



An there you have it, how much is someone willing to pay for space in the
Internet casino. Well, it's much more than free and probably close to the
dollar level in the presentation by Lee Howard at an ARIN meeting (I think
it was in Barbados or maybe I have that meeting place wrong and it was
NANOG) ... Well, $40/month per IP address will be the pain level for all
customers to finally cash-in the IPv4 chips and move to IPv6.

I wish it was Barbados!
NANOG56. 
http://www.nanog.org/meetings/nanog56/presentations/Wednesday/wed.general.h
oward.24.wmv




Thus far, IPv6 has been the Field of Dreams  those of us who have
built it, we know they have not yet come  (the IPv6 customers).  That's
all this discussion is really about is when will they come.

Some of us have quite a few IPv6 customers:
http://www.worldipv6launch.org/measurements/
And we see significant traffic from those users.  :-)



I know the core of the Internet will be IPv4 for many years. All one has
to do is talk to a few customer to find out that they are in no hurry.
It's a no-brainer, because , none of us charges a customer more than than
lunch money for an IPv4 address.

Depends on what you mean by core. For some values of core, the
Internet is already dual-stack.


Now, if you tell me all the porn site owners were great net citizens,
ready to move to IPv6 and shut off IPv4 access, well then I can see things
moving along much faster.

Feel free to offer them a discount for dual-stack, and a deeper discount
for IPv6-only.
Unfortunately, I don't know any porn site operators, so I haven't been
able to have conversations with them about the economics of IPv6.

Lee

Re: misunderstanding scale

[Lee Howard]

It is late and I am just rambling, but even with DHCP(4and6) changing IP
networks is not a trivial thing. Not hard, but it will require a lot more
planning than what many do today of simply changing the WAN IP address
and some records in the DNS (if needed)

We tried:  http://tools.ietf.org/wg/6renum
In particular, you may want to read http://tools.ietf.org/html/rfc6879
when planning and renumbering IPv6; it's intended to save you pain later.

Lee

Re: misunderstanding scale

[Lee Howard]

On 3/24/14 1:37 PM, William Herrin b...@herrin.us wrote:

On Mon, Mar 24, 2014 at 9:25 AM, Joe Greco jgr...@ns.sol.net wrote:
 I say this with the utmost respect, but you must understand the
 principle of defense in depth in order to make competent security
 decisions for your organization. Smart people disagree on the details
 but the principle is not only iron clad, it applies to all forms of
 security, not just IP network security.

 The problem here is that what's actually going on is that you're now
 enshrining as a security device a hacky, ill-conceived workaround
 for a lack of flexibility/space/etc in IPv4.  NAT was not designed
 to act as a security feature.

Hi Joe,

That would be one of those details on which smart people disagree.
In this case, I think you're wrong. Modern NAT superseded the
transparent proxies and bastion hosts of the '90s because it does the
same security job a little more smoothly. And proxies WERE designed to
act as a security feature.

What kinds of devices are we talking about here?  Are we talking about the
default NAT on a home network router, or an enterprise-level NAT operating
on a firewall?

The NAT on home gateways may be a full-cone NAT. This allows easier setup
of online gaming, for instance, or other applications where an inbound SYN
is required.  This provides no security, since as soon as a connection is
established, all traffic is allowed. Even restricted cone NATs provide
little protection, just a bit of guessing that even a human could manage.

If we're talking about an enterprise firewall, then I don't
understand--we're talking about a firewall.  If it implements a symmetric
NAT in addition to a stateful firewall, then it's implementing the same
function twice.  But, hey, it's your network, if
security-through-obscurity is one of your defense in depth layers, that's
fine.  You may use NPT66 with ULA; that function is defined.

Lee

Re: Updated ARIN allocation information

[Lee Howard]

On 1/29/14 5:01 PM, Leslie Nobile lesl...@arin.net wrote:


ARIN would like to share two items of information that may be of interest
to the community.

First, ARIN has recently begun to issue address space from its last
contiguous /8, 104.0.0.0 /8.  The minimum allocation size for this /8
will be a /24.  You may wish to adjust any filters you have in place
accordingly.

I was surprised that ARIN started issuing from this /8.  I thought it
still had a /9 and a /10 in inventory.



Additionally, ARIN has placed  23.128.0.0/10 in its reserves in
accordance with the policy Dedicated IPv4 block to facilitate IPv6
Deployment (NRPM 4.10).  There have been no allocations made from this
block as of yet, however, once we do begin issuing from this block, the
minimum allocation size for this /10 will be a /28 and the maximum
allocation size will be a /24.  You may wish to adjust any filters you
have in place accordingly.

I see the note at 
https://www.arin.net/resources/request/ipv4_countdown.html
that this block is not included in inventory.  Thanks for that.

Lee

Re: Verizon FIOS IPv6?

[Lee Howard]

On 1/8/14 9:34 AM, Brian Henson marin...@gmail.com wrote:

The only major ISP that I seen so far that has rolled out is Comcast. Been
probing the TW Cable people for months to see what their plans are for
IPv6
in Ohio and all I have gotten is a million different stories.

TWC Ohio (residential service):  Real Soon Now.

For what it's worth, ATT also has a significant rollout on U-Verse.
http://www.worldipv6launch.org/measurements/

I've read in some forums that there are pockets of FiOS users with IPv6
running. I've seen LLA on ActionTec modems. Something tells me that they
will sneak up on us with a sudden deployment.

Lee




On Wed, Jan 8, 2014 at 5:29 AM, Justin M. Streiner
strei...@cluebyfour.orgwrote:

 On Wed, 8 Jan 2014, George, Wes wrote:

  Interestingly, I have one of the later-generation ActionTecs, and VZ
 pushed a software update to it at some point and it sprouted IPv6
config.


 I noticed the same thing on my router several months ago, but when I
 called to see if I could get IPv6 turned on for my account, no go.

 jms

Re: turning on comcast v6

[Lee Howard]

From:  Matthew Petach mpet...@netflight.com
Date:  Saturday, December 21, 2013 10:55 PM
To:  Lee Howard l...@asgard.org
Cc:  Jamie Bowden ja...@photon.com, Owen DeLong o...@delong.com,
m...@kenweb.org m...@kenweb.org, nanog@nanog.org nanog@nanog.org
 
 So there's an interesting question.  You suggest there's a disagreement
 between enterprise network operators and protocol designers. Who should
 change?
 
 I used to run an enterprise network. It was very different from an ISP
 network. I didn't say, You're wrong! I said, What's missing?
 
 default route information via DHCPv6.  That's what I'm still waiting for.

Why?
You say, The protocol suite doesn't meet my needs; I need default gateway
in DHCPv6.  So the IETF WG must change for you to deploy IPv6.  Why?

Lee

 
 Matt
  

Re: turning on comcast v6

[Lee Howard]

On 12/30/13 11:19 AM, Leo Bicknell bickn...@ufp.org wrote:


On Dec 24, 2013, at 8:15 AM, Lee Howard l...@asgard.org wrote:

 Why?
 You say, The protocol suite doesn't meet my needs; I need default
gateway
 in DHCPv6.  So the IETF WG must change for you to deploy IPv6.  Why?

Why must the people who want it justify to _you_?

They don't; they have to justify it to the DHC WG at IETF, in order to
generate consensus.


This is fundamental part I've not gotten about the IPv6 crowd.  IPv4 got
to
where it is by letting people extend it and develop new protocols and
solutions.
DHCP did not exist when IPv4 was created, it was tacked on later.  Now
people want to tack something on to IPv6 to make it more useful to them.
Why do they need to explain it to you, if it doesn't affect your
deployments
at all?

You can provision your network any way you like.  If you want to create a
custom version of DHCP (or your own provisioning protocol), that's fine.
There doesn't seem to be consensus that default gateway in DHCP is a good
idea. There's running code for how to change this.



Some of us think the model where a DHCP server knows the subnet and hands
out
a default gateway provides operational advantages.  It's an opinion.  And
the
current IPv6 crowds view that not having a default route and relaying on
RA's
is better is also an opinion.

We've spent years of wasted bits and oxygen on ONE STUPID FIELD IN DHCP.
Put
it in their, and let the market sort it out, unless you can justify some
dire
harm from doing so.

I don't like the let many flowers bloom model of protocol development.
You end up with a lot of cruft in protocols. Successful protocols tend not
to have that (at least, when they become successful). I don't know if it
will do harm (though it's easy to imagine DHCP not aligning with default
gateways in modern, more mobile networks).  But if the barrier for adding
fields is Eh, it probably won't cause dire harm then we would have
pretty messy protocols.


What is more important fast IPv6 adoption or belittling people who want
to 
deploy it in some slightly different way than you did?

Did I belittle anybody?  I apologize if I did that.  It certainly was not
my intent. I'm trying to understand a point of view.

Lee



-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/

Re: turning on comcast v6

[Lee Howard]

On 12/30/13 1:04 PM, Ryan Harden harde...@uchicago.edu wrote:

On Dec 24, 2013, at 8:15 AM, Lee Howard l...@asgard.org wrote:

 default route information via DHCPv6.  That's what I'm still waiting
for.
 
 Why?
 You say, The protocol suite doesn't meet my needs; I need default
gateway
 in DHCPv6.  So the IETF WG must change for you to deploy IPv6.  Why?
 
 Lee

There are many places that wish to severely restrict or even block RA.
Implementations of Captive Portal/NetReg/Bump in the wire auth/etc like
to do redirection based on MAC. Many are doing this with very short DHCP
leases that hand out different name servers and/or gateways until you
properly auth via $method. You might be able to do this with something
like RADVD, but when you have systems that have been doing this for IPv4
for years, there¹s little interest (read: budget) in rewriting everything
for IPv6.

Thank you very much for presenting an actual use case.
Seems like a dot1x kind of application, where the host is in a temporary
VLAN until authenticated (etc.), right?  Same use case, different network
solution.



'Rewrite all of your tools and change your long standing business
practices¹ is a very large barrier to entry to IPv6. If adding gateway as
an optional field will help people get over that barrier, why not add it?
Sure it doesn¹t fit into the ³IPv6 way,² but bean counters don¹t care
much for that when you have to ask for developer time to rewrite
everything.


Well, the tools have to be rewritten to support IPv6 fields, sockets, and
structures anyway.  However, there's a difference between, Make sure you
call IP family agnostic libraries and increase field sizes, then let it
run and Rebuild your network security.  DHCP+RA just works in most
networks; this is a use case where it could be made to work, but only by
changing the network.

As for why not add it? my answer is that if it's needed, we should add
it. If it's not needed, we should not add it. I want default gateway in
DHCPv6 does not answer the question of whether it's needed, which is why
I asked why.


 

Disclaimer: I don¹t condone said methods and trickery mentioned above,
just pointing out their use.

Will consider more.

Lee



/Ryan

Re: turning on comcast v6

[Lee Howard]

On 12/30/13 2:20 PM, Ryan Harden harde...@uchicago.edu wrote:

On Dec 30, 2013, at 12:58 PM, Lee Howard l...@asgard.org wrote:

 
 
 'Rewrite all of your tools and change your long standing business
 practices¹ is a very large barrier to entry to IPv6. If adding gateway
as
 an optional field will help people get over that barrier, why not add
it?
 Sure it doesn¹t fit into the ³IPv6 way,² but bean counters don¹t care
 much for that when you have to ask for developer time to rewrite
 everything.
 
 
 Well, the tools have to be rewritten to support IPv6 fields, sockets,
and
 structures anyway.  However, there's a difference between, Make sure
you
 call IP family agnostic libraries and increase field sizes, then let it
 run and Rebuild your network security.  DHCP+RA just works in most
 networks; this is a use case where it could be made to work, but only by
 changing the network.

Updating tools to add a box for IPv6 fields and tweaking the backend to
generate a config file for DHCPv6 which is very similar to DHCP(for v4)
is a lot different/easier than having to rewrite and/or split your
backend to generate output in a completely different format. However, I'm
not as familiar with RADVD as I am with isc-dhcpd so that might be a bad
argument.

And you don't have to support IPv6 from top to bottom to roll out IPv6 to
users. So rewriting for socket support isn't necessary day one. You can
route IPv6 for users so they can reach the IPv6 world quickly, then add
local services as time/money allows. The biggest driver for IPv6 will be
external resources available only via IPv6, not local. (Of course this is
from the point of view where your business' primary service isn't outward
facing resources.)

I agree with you on the above, I just didn't say so very well.


I'm sure DHCP+RA works for most, but there are IPv4 shops who swear by
fully dynamic DHCP, some who do DHCP-Reservations, and some who go static
only. Just like some shops are EIGRP, some OSPF, and some ISIS. IMO IPv6
needs to be flexible enough to handle the fact that not everyone builds
identical architectures nor do they have the exact same needs. Being able
to use DHCPv6+RA, RA only, or DHCPv6 only should all be viable options.
Forcing everyone down the same path will just lead to stupid proprietary
solutions to a problem that shouldn't exist in the first place.

All of those cases work just as well with DHCP+RA.
Only in cases where a router on a subnet is not the correct gateway is RA
a problem, AFAIK. You gave one example where that's the case.  Another
would be where there are two gateways for the same network segment, which
don't share an IP address, and you want DHCP to tell hosts which one they
should use (rather than, say, manual configuration or GPO).
DHCP and RAs do different things.  DHCP does host configuration.  Router
Advertisements advertise routers. When you have both, you can leave off a
field in DHCP, and rely on the network to route the packets. Turning off
RAs and putting that information into DHCP for each subnet you manage
means additional work.  It's not a lot of work, admittedly.

 
Lee


/Ryan

Re: turning on comcast v6

[Lee Howard]

I'm not really an advocate for or against DHCP or RAs.  I really just want
to understand what feature is missing.

From:  Blake Dunlap iki...@gmail.com
Date:  Monday, December 30, 2013 3:19 PM
To:  Ryan Harden harde...@uchicago.edu
Cc:  Lee Howard l...@asgard.org, Jamie Bowden ja...@photon.com,
nanog@nanog.org nanog@nanog.org
Subject:  Re: turning on comcast v6

 The better question is are you using RIP or ICMP to set gateways in your
 network now?

I disagree that that's a better question.
I'm not using RIP because my hosts don't support it (at least, not without
additional configuration), and it would be a very unusual configuration,
adding weight and complexity for no benefit.  RAs are the opposite.
Not even sure how you would use ICMP to set a default gateway.  Maybe
there's a field I'm unaware of.

 
 
 If you don't use those now, why is RA a better solution in ipv6?

It's built into the fundamentals of IPv6, using the Neighbor Discovery
Protocol.  It's supported in every stack.  It's the default mode of
operation.  To turn it off, you have to disable part, but not all, of NDP.
(Do you also turn off RSs on all hosts?)

There could be better solutions; I would like to understand how they are
better.  Again, in your network, you can do whatever you want.  If you want
something different standardized, then you need consensus here:
https://www.ietf.org/mailman/listinfo/dhcwg

Lee