RE: IPv6 end user addressing

[Cameron]

> -Original Message-
> From: William Herrin [mailto:b...@herrin.us]
> Sent: Tuesday, 9 August 2011 2:30 PM
> To: Chris Adams; nanog@nanog.org
> Subject: Re: IPv6 end user addressing
> 
> When I send someone on site to do work for me, I don't want to have to
> prepare excessive instructions on how to connect their laptop to the
> local LAN. I want to say, "This switch, this port" and then move on to
> the actual work I sent them there to do.

To be fair, if you're sending someone to site who isn't familiar with
putting a static address on their laptop then you're probably doing things
wrong to begin with.

This line of argument isn't going to get us anywhere as for server networks,
the benefits of using a /64 are not necessarily beneficial given the
environment.


> You're welcome to run your shop your way.
> 
> Regards,
> Bill Herrin
> 
> 
> --
> William D. Herrin  her...@dirtside.com  b...@herrin.us
> 3005 Crane Dr. .. Web: 
> Falls Church, VA 22042-3004

Free(opensource) Ticketing solutions

[Cameron Sharp]

Can heavily recommend Freescout

Cameron

- Original message -
From: Pascal Masha 
To: nanog 
Subject: Free(opensource) Ticketing solutions
Date: Monday, 27 May 2024 18:28

Hello,

Which free and good ticketing systems do you folks(for those who do) use?

Regards,
Paschal Masha

Re: Mobile Operator Connectivity

[Cameron Byrne]

On Sun, Oct 10, 2010 at 10:42 AM, Joel Jaeggli  wrote:
> On 10/9/10 5:08 PM, Ryan Finnesey wrote:
>> I have been working on a similar project and I am finding it very hard
>> to get the mobile operators to understand why we want as little latency
>> as possible and they are not very open to people peering with their
>> "wireless" backbone.
>
> Possibly because the way that they tunnel GTP to the GGSN and the
> locations of GGSN devices relative to the handsets served preclude as
> little latency as possible.
>

Yes.  Some mobile providers are more heavily aggregated than others.

I have been pushing for decreasing the architectural latency in the
mobile architecture with IPv6

http://www.youtube.com/watch?v=1GlRgaFriYU#t=29m45

But there are a lot of roadblocks, some more technical than others.

Also, the wireless providers generally don't have a point of presence
in the peering NAPs.   I have run this business case a few times for
my company and it generally is a financial wash, and therefore not
worth the effort to deploy and support additional transport and nodes
at the peering locations.  It's simpler and cheaper to just punt the
Internet traffic out of the wireless networks as soon as possible to
an ISP, and those ISP frequently own the fiber transport as well.
But, like anything, you can always ask your B2B account manager for a
special setup.  There are special setups that i know for corporate
customers.


>> I hope this will change with more and more
>> eyeballs going wireless.
>
> LTE provides an opportunity to move the bottleneck.
>

LTE provides some latency benefits on the wireless interface, but the
actual packet core architecture is very similar to GSM / UMTS.

For those concerned about latency, the key is working with the
wireless operator to find where the mobility aggregation points are
and how they are connected to the Internet.  More advanced
applications at large scale can justify direct peering, but i don't
imagine that achieves much real latency benefits over just being
properly coordinated with the locations and ISPs.

Cameron
===
http://groups.google.com/group/tmoipv6beta
===

Re: T-Mobile USA - Peering Policy

[Cameron Byrne]

On Tue, Oct 12, 2010 at 9:28 PM, Ryan Finnesey
 wrote:
> Can someone on the list from T-Mobile USA please contact me.  I have
> tried sending a message to ad...@tmodns.net but the message bounces back
> and the mailbox for arintechcont...@t-mobile.com is full.   I am trying
> to find out information regarding there peering policy.
>

You can contact me off-list for T-Mobile USA questions.

Cameron

Re: Only 5x IPv4 /8 remaining at IANA

[Cameron Byrne]

On Tue, Oct 19, 2010 at 5:05 PM, Mark Smith
 wrote:
> On Tue, 19 Oct 2010 16:25:12 -0700
> Zaid Ali  wrote:
>
>>
>> On 10/19/10 3:58 PM, "Mark Andrews"  wrote:
>>
>> > Adding is seperate IPv6 server is a work around and runs the risk
>> > of being overloaded.
>>
>> And what a wonderful problem to have! You can show a CFO a nice cacti graph
>> of IPv6 growth so you can justify him/her to sign off on IPv6 expenses. A
>> CFO will never act unless there is a real business problem.
>
> When did CFOs run the company? If you're taking this decision to C
> level management, the CIO, CTO or the CEO should be the ones making the
> decision. They direct where money goes, not the CFO.
>

True. But, i will say, at my employer, the CFO does control the
corporate risk management group that oversees the business continuity
strategy.  Without IP addresses, we can't grow the business, and
that's a problem.  So, the CFO is a stake holder where i work.  Along
the lines of IPv6 for business continuity, i usually point people to
this ARIN link which is very official and makes it clear the IPv4
addresses are running out, there is a risk to manage.  The CFO tries
to make sure the money we spend is spent wisely, IPv6 does not
directly drive new revenues, but it does diffuse the IP exhaust
crisis. It's simply about business continuity.  That is something all
the CxOs can understand clearly.

https://www.arin.net/knowledge/about_resources/ceo_letter.pdf


> The easy business case for IPv6 is insurance. At some point in the
> relatively near future there may be content or services that are only
> available over IPv6. Investing in IPv6 deployment now is insurance
> against not being able to access that content when you may need to in
> the future. Do your management want to miss out on being able to
> access the next IPv6-only Google, Salesforce.com, etc., when it is
> critical to the business? Somebody in the organisation will have
> responsibility for ensuring continued and reliable access to services
> the company needs, and if that includes Internet access, then IPv6 is
> going to become an essential part of that continued and reliable
> Internet access.
>

Agreed. But, I'll flip it around on you.  Same idea, but many mobile
eyeballs are going IPv6-only.   If you are a content provider and you
want to make sure people can see your website, then you will want to
be on IPv6.


>> There are some
>> of us here who have management with clue but there are many that don't,
>> sadly this is the majority and a large contributor to the slow adoption of
>> IPv6.

It's the old story, pay a little now to have an IPv6 plan and get the
wheels moving.  Or, be caught flat footed, and pay a lot later in
forklift upgrades and lost customers.

Cameron
==
http://groups.google.com/group/tmoipv6beta
==

Re: Only 5x IPv4 /8 remaining at IANA

[Cameron Byrne]

On Thu, Oct 21, 2010 at 8:07 AM, Ben Butler  wrote:
> Hi,
>
> Showing my ignorance here, but this is one of the things I have wondered, 
> given that we run both v4 and v6 for a period of time on the Internet, 
> presumably at one time or another a particular resource may only be able in 
> v4 land, then v4 and v6, then finally v6 only.
>
> I have never been particularly clear how an end network that exists only in 
> v4 or v6 address space is able to access a resource that only exists in the 
> other.  Is can sort of see some freaking huge NAT box type thing that 
> summarizes v6 in a v4 address scope or contains the v4 address range at some 
> point inside the v6 address space - but how can a v4 host get to a hot in v6 
> world that sits outside this without going through some form of proxy / nat 
> gateway between the two.
>
> Or are the two simply not inter-communicable?
>
> Ben
>
> -Original Message-
> From: Patrick Giagnocavo [mailto:patr...@zill.net]
> Sent: 21 October 2010 15:59
> To: Owen DeLong; NANOG
> Subject: Re: Only 5x IPv4 /8 remaining at IANA
>
> On 10/21/2010 4:28 AM, Owen DeLong wrote:
>
>>> Actually for those of my clients in one location, it served as an
>>> impetus to extend a contract with Level3 for another 3 years - with
>>> their existing allocation of a /24 of IPv4 addresses included.
>>
>> All well and good until some of their customers are on IPv6...
>> Then what?
>
> I'm sorry, can you expand on exactly what you mean by this?
>
> Are IPv6 connected machines unable to access IPv4 addresses?

IPv6->IPv4 is called NAT64, and it works today pretty well. Most
things work very well (web, email, ...), somethings don't (skype ..)


http://www.youtube.com/watch?v=AmjlptEva4Y#t=1h32m26s
http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-12
http://ecdysis.viagenie.ca/

As your major NAT vendor, they probably have NAT64 in the road map for
the next 6 to 12 months.

IPv4->IPv6 initiated connection are a lost cause that cannot scale in
any good way.

Cameron

Re: Only 5x IPv4 /8 remaining at IANA

[Cameron Byrne]

On Thu, Oct 21, 2010 at 8:26 AM, Patrick Giagnocavo  wrote:
> On 10/21/2010 11:08 AM, Jeroen Massar wrote:
>>> On 2010-10-21 16:59, Patrick Giagnocavo wrote:
>>> Are IPv6 connected machines unable to access IPv4 addresses?
>>
>> Unless you put a application/protocol translation in the middle IPv6
>> can't talk to IPv4. yahoo("IVI","Ecdysis NAT64") for two possibilities
>> one have for that, oh and yahoo("IPv6Gate") for a ready-to-use HTTP
>> specific one.
>>
>> But if you didn't know that fact, you might want to invest in a proper
>> book about IPv6 and read up quite a bit. As this is NANOG, a good
>> operational book is "Running IPv6".
>>
>
> Thank you for the book recommendation; however, I was trying to get an
> admission that any IPv6-connected end users or corporate connections,
> will be accessing IPv4-only resources for a long time to come, i.e.
> years and years.
>
> And that the responsibility for IPv6 to v4 connection won't have to be
> handled by my client with a few racks.

That depends if your clients application and content works well via
NAT64.  If you are just serving web pages and you always use FQDNS,
great.  You are pretty set for a long time.

If not, you use IPv4 literals, you may end up on this list,
http://groups.google.com/group/ipv4literals and you will have to
either modify your application to work via NAT64 or enable IPv6
natively on your side or... have some portion of the internet not
reach your services.  The better long term strategy is to go ipv6 and
take the risk out of all this hedging against the inevitable of LSN /
CGN / AFTR.  That is what Google, Facebook, and many others are
already doing.

If a major service provider rolls out IPv6-only devices and services
(and they are / will, because IPv4 is out) they will not make a
special case for you.  So, what you really need to do is figure out if
your applications and content work via NAT64 and come up with a good
plan for going IPv6 in the long run. It's all about your risk
tolerance


Cameron
=
http://groups.google.com/group/tmoipv6beta
=

Re: IPv4 sunset date revised : 2009-02-05

[Cameron Byrne]

On Thu, Oct 21, 2010 at 10:20 PM, George Bonser  wrote:
>
>
>> -Original Message-
>> From: Christopher Morrow > Sent: Thursday, October 21, 2010 9:49 PM
>> To: bmanning
>> Cc: NANOG
>> Subject: Re: IPv4 sunset date revised : 2009-02-05
>
>
>>
>> (now I'm teasing.. .Bill where's your docs on this fantastic new
>> teknowlogie?)
>>
>
> I found it here:
>
> http://www.ivi2.org/
>
> But the readme is a bit confusing:
>
> http://www.ivi2.org/code/00-ivi0.5-README
>
> Trying to figure out how they map a /70 v6 prefix to a /30 v4 prefix
> assuming the mapping is to be 1-1
>

Right, 1 to 1 does not solve any IPv4 exhaustion problems.

Going back to the title of the thread, IVI does not help you sunset
IPv4 since the same amount of IPv4 is required.

NAT64 is the protocol that helps you "sunset" IPv4 by providing native
IPv6 to the user and doing a protocol translation similar to NAPT to
IPv4 destination.

Thusly, IPv6 end to end applications benefit from not having a middle
box and experience more features (e2e) and less flaky NAPT, ... keep
in mind that NAPT is the status quo in many places, especially in
mobile wireless, end to end IPv6 is an upgrade.  This is pretty
impactful since major internet destinations like Google, Netflix,
Facebook have IPv6 deployments in place today.  For many, this is a
~50% reduction in NAT which is ~50% increase in E2E communication
(less cost, better quality).  Since economics and user experience are
involved, this is a real path to migrating from IPv4 to IPv6.  The
right incentive structure is in place for both the service provider
who is out of addresses and the consumer who wants rich e2e
communication.

Shameless plug, i have it working here for over 9 months
http://groups.google.com/group/tmoipv6beta

Cameron

Re: IPv4 sunset date revised : 2009-02-05

[Cameron Byrne]

On Fri, Oct 22, 2010 at 10:54 AM,   wrote:
> On Fri, Oct 22, 2010 at 09:42:50AM -0700, Cameron Byrne wrote:
>> On Thu, Oct 21, 2010 at 10:20 PM, George Bonser  wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: Christopher Morrow > Sent: Thursday, October 21, 2010 9:49 PM
>> >> To: bmanning
>> >> Cc: NANOG
>> >> Subject: Re: IPv4 sunset date revised : 2009-02-05
>> >
>> >
>> >>
>> >> (now I'm teasing.. .Bill where's your docs on this fantastic new
>> >> teknowlogie?)
>> >>
>> >
>> > I found it here:
>> >
>> > http://www.ivi2.org/
>> >
>> > But the readme is a bit confusing:
>> >
>> > http://www.ivi2.org/code/00-ivi0.5-README
>> >
>> > Trying to figure out how they map a /70 v6 prefix to a /30 v4 prefix
>> > assuming the mapping is to be 1-1
>> >
>>
>> Right, 1 to 1 does not solve any IPv4 exhaustion problems.
>
>
>        ah... but the trick is to only need enough IPv4 in the pool
>        to dynamically talk to the Internet.  Native v6 to Native v6
>        never has to drop back to the Internet, It uses native v6
>        paths.  So the larger the v6 uptake, the fewer Internet addreses
>        you'll need to keep around in your pool.
>
>
>> Going back to the title of the thread, IVI does not help you sunset
>> IPv4 since the same amount of IPv4 is required.
>
>        See above.
>

So works, just not at a large scale.  For larger scale, you need
address sharing like NAT64.

Re: IPv6

[Cameron Byrne]

On Thu, Nov 18, 2010 at 1:39 PM, Nick Olsen  wrote:
> Curious as to who is running IPv6 with TW Telecom or Cogent.
> I'm wanting to turn up native IPv6 with them, And wanted to hear
> thoughts/experiences.
> I assume it should be a "non-event". We've already got a prefix from arin
> that we are going to announce.

TWT is no problem with IPv6.

Re: IPv6

[Cameron Byrne]

On Thu, Nov 18, 2010 at 2:44 PM, Mike Tancsa  wrote:
> On 11/18/2010 5:14 PM, Lee Riemer wrote:
>> Try tracerouting to 2001:500:4:13::81 (www.arin.net) or
>> 2001:470:0:76::2 (www.he.net) via Cogent.
>>
>
> Interesting. I noticed a similar issue with  ipv6.cnn.com today. I dont
> see it via TATA, but see it via Cogent.  So whats the story behind it
> and ARIN not being seen through cogent ?  Is it due to no v6 relation
> bewtween he.net and Cogent ?
>
> 2620:0:2200:8::::8901  (whats with the crazy 8s?)
>

Wow.  CNN now has IPv6.  That's awesome.  I guess i missed the memo.

So, major players with IPv6 are?

ipv6.cnn.com (just book marked it)

ipv6.comcast.net

ipv6.google.com (or you can have it all with a white-list)

www.ipv6.cisco.com

www.v6.facebook.com
m.v6.facebook.com

ipv6.t-mobile.com (admittedly, not major a major content source, but it's mine)


And, then debunking the "dual-stack is too risky" notion is
www.ucla.edu (which is a big business by most measures) and serves
 and A records without a white-list or special FQDN.

I have predicted that by the end of 2011 nearly ~50% of my network
traffic (mobile provider) can be served by IPv6 natively end to end.
I think a lot of folks that measure Facebook and Google (including
YouTube)  traffic today can see how that is feasible given current
volumes and rates of growth.  Hence, the viability of IPv6-only
endpoints (especially mobile) with NAT64/DNS64 as truly connecting the
IPv4 long-tail remaining 50% that will continue to shrink as more
major sites follow the CNN's path.

Cameron
===
http://groups.google.com/group/tmoipv6beta
===

Re: IPv6

[Cameron Byrne]

On Thu, Nov 18, 2010 at 3:17 PM, Cameron Byrne  wrote:
> On Thu, Nov 18, 2010 at 2:44 PM, Mike Tancsa  wrote:
>> On 11/18/2010 5:14 PM, Lee Riemer wrote:
>>> Try tracerouting to 2001:500:4:13::81 (www.arin.net) or
>>> 2001:470:0:76::2 (www.he.net) via Cogent.
>>>
>>
>> Interesting. I noticed a similar issue with  ipv6.cnn.com today. I dont
>> see it via TATA, but see it via Cogent.  So whats the story behind it
>> and ARIN not being seen through cogent ?  Is it due to no v6 relation
>> bewtween he.net and Cogent ?
>>
>> 2620:0:2200:8::::8901  (whats with the crazy 8s?)
>>
>
> Wow.  CNN now has IPv6.  That's awesome.  I guess i missed the memo.
>
> So, major players with IPv6 are?
>
> ipv6.cnn.com (just book marked it)
>
> ipv6.comcast.net
>
> ipv6.google.com (or you can have it all with a white-list)
>
> www.ipv6.cisco.com
>
> www.v6.facebook.com
> m.v6.facebook.com
>
> ipv6.t-mobile.com (admittedly, not major a major content source, but it's 
> mine)
>
>

Yahoo just dropped in on the IPv6 content party

http://ipv6.weather.yahoo.com/

I just bookmarked it.  Well done Yahoos.

Cameron
 ===
 http://groups.google.com/group/tmoipv6beta
 ===


> And, then debunking the "dual-stack is too risky" notion is
> www.ucla.edu (which is a big business by most measures) and serves
>  and A records without a white-list or special FQDN.
>
> I have predicted that by the end of 2011 nearly ~50% of my network
> traffic (mobile provider) can be served by IPv6 natively end to end.
> I think a lot of folks that measure Facebook and Google (including
> YouTube)  traffic today can see how that is feasible given current
> volumes and rates of growth.  Hence, the viability of IPv6-only
> endpoints (especially mobile) with NAT64/DNS64 as truly connecting the
> IPv4 long-tail remaining 50% that will continue to shrink as more
> major sites follow the CNN's path.
>
> Cameron
> ===
> http://groups.google.com/group/tmoipv6beta
> ===
>

Re: IPv6

[Cameron Byrne]

On Sun, Nov 21, 2010 at 1:41 PM, Grzegorz Janoszka  wrote:
> On 21-11-10 22:31, Cameron Byrne wrote:
>>
>> Yahoo just dropped in on the IPv6 content party
>> http://ipv6.weather.yahoo.com/
>> I just bookmarked it.  Well done Yahoos.
>
> Well,
>
> ipv6.ycpi.ops.yahoo.net has IPv6 address 2a00:1288:f006:1fe::1000
> ipv6.ycpi.ops.yahoo.net has IPv6 address 2001:4998:f00b:1fe::1000
> ipv6.ycpi.ops.yahoo.net has IPv6 address 2001:4998:f011:1fe::1000
>

These routes are all in route-views.oregon-ix.net

Most importantly, i am on the Comcast IPv6 trial and the T-Mobile USA
IPv6 trial and ipv6.weather.yahoo.com loads well for both.

route-views>sh ipv6 route 2001:4998:f011:1fe::1000
Routing entry for 2001:4998:F011::/48
  Known via "bgp 6447", distance 20, metric 0, type external
  Route count is 1/1, share count 0
  Routing paths:
2001:470:0:1A::1
  Last updated 3w5d ago

route-views>show ipv6  route 2a00:1288:f006:1fe::1000
Routing entry for 2A00:1288::/32
  Known via "bgp 6447", distance 20, metric 0, type external
  Route count is 1/1, share count 0
  Routing paths:
2001:470:0:1A::1
  Last updated 7w0d ago

route-views>sh ipv6 route 2001:4998:f00b:1fe::1000
Routing entry for 2001:4998::/32
  Known via "bgp 6447", distance 20, metric 0, type external
  Route count is 1/1, share count 0
  Routing paths:
2001:B08:2:280::4:100
  Last updated 2d01h ago

route-views>

Cameron
===
http://groups.google.com/group/tmoipv6beta
===


> In my bgp I see only the first address, I don't see any path to two others.
> Do you have the route to them?
>
> --
> Grzegorz Janoszka
>
>

Re: IPv6

[Cameron Byrne]

On Sun, Nov 21, 2010 at 2:05 PM, George Bonser  wrote:
>>
>> Well,
>>
>> ipv6.ycpi.ops.yahoo.net has IPv6 address 2a00:1288:f006:1fe::1000
>> ipv6.ycpi.ops.yahoo.net has IPv6 address 2001:4998:f00b:1fe::1000
>> ipv6.ycpi.ops.yahoo.net has IPv6 address 2001:4998:f011:1fe::1000
>>
>> In my bgp I see only the first address, I don't see any path to two
>> others. Do you have the route to them?
>>
>
> I see two of them directly from yahoo : 2001:4998::/32 (that covers the
> last two IPs) but the first one comes to me via HE (2a00:1288::/32)
>
> You think many people are going to type the "v6" part of the URL
> considering most people when they get v6 won't even know if they have it
> or not?
>

Only people that know what they want will type the ipv6.*.example.com
stuff.  It's self selecting.  This will keep the non-techies away from
the new IPv6 deployments while the network operators and content
providers work out the kinks.

I believe the life-cycle for IPv6 introduction at the biggest web
sites will be ipv6.*.example.com, then ipv6 DNS white list, then open
the flood gates.  Other sites will go directly to opening the flood
gates depending on their user profiles.  There is a lot of great work
going on to see what the risk is for opening  to all users

http://www.fud.no/ipv6/

Here is one take on the discussion of whitelist

http://tools.ietf.org/html/draft-livingood-dns-whitelisting-implications-01

Cameron
==
http://groups.google.com/group/tmoipv6beta
==
>
>
>

Re: Level 3 Communications Issues Statement Concerning Comcast'sActions

[Cameron Byrne]

On Mon, Nov 29, 2010 at 10:34 PM, Owen DeLong  wrote:
>
> On Nov 29, 2010, at 9:09 PM, Andrew Koch wrote:
>
>> On Mon, Nov 29, 2010 at 22:17, William Herrin  wrote:
>>
>>> So you're saying: treat it like electrical service. I have a 200 amp
>>> electrical service at my house. But I don't pay for a 200 amp service,
>>> I pay for kilowatt-hours of usage.
>>>
>>> There are several problems transplanting that billing model to
>>> Internet service. The first you've already noticed - marketing
>>> activity has rendered it unsalable. But that's not the only problem.
>>
>> Not quite.  Look at mobile data plans.  A very few are unlimited, most
>> are per byte.
>>
> And I am on Sprint because they are one of the few.
>
>>> Another problem is that the price of electricity has been very stable
>>> for a very long time, as has the general character of devices which
>>> consume it. Consumers have a gut understanding of the cost of leaving
>>> the light on. But what is a byte? How much to load that web page?
>>> Watch that movie? And doesn't Moore's Law mean that 18 months from now
>>> it should cost half as much? If I can't tell whether or not I'm being
>>> ripped off, I'm probably being ripped off.
>>
>> Yep, sure seems that way when I get my mobile bill with roaming data
>> charges.  Consumers learn what it costs per byte, apps are created for
>> them to manage their download amounts.  Carriers send messages
>> alerting consumers of their usage.
>>
> I simply avoid using roaming services. Frankly, my carrier could double
> their revenue from me and significantly increase their profits if they
> would offer me a global unlimited data/voice plan for twice what I currently
> pay for domestic. (If any of you cellular companies are listening, that's
> right, I'd be willing to pay ~$250/month for global unlimited voice/data
> and my usage would not increase very much above what you're already
> providing). I also happen to know that I'm not the only consumer that
> would very much like to be able to purchase this kind of service.
>

An alternative to N number of SIM cards or paying high roaming fees is
WiFi calling from cellular using UMA or GAN technologies.  I used the
T-Mobile USA Blackberry Curve to call Philly from a free WiFi access
point at a Shanghai coffee shop, worked fine. Skype probably works
too.  Yes, it only works while on WiFi, but when you are attached via
wifi it is like being attached via the home network from a billing
perspective.  While on WiFi, voice, txt, and web all work. For me, it
is a reasonable compromise when compared to roaming fees.

Shameless plug http://tinyurl.com/2vqzcrv

And, for the IPv6 enthusiast, the Nokia E73 does both GAN (wifi
calling) and IPv6 on T-Mobile's 3G network (but not together...
beta...)

Cameron
(not an unbiased source of information on america's largest 4G network)

> Owen
>
>
>

Re: Start accepting longer prefixes as IPv4 depletes?

[Cameron Byrne]

On Wed, Dec 8, 2010 at 11:07 AM, George Bonser  wrote:
>>
>> Just move to v6, already.  v4 is done.  trying to keep it on life
>> support
>> is going to cost everyone time, money, and reduced life span due to
>> increased stress.
>
> Exactly.  People need to adopt the "v4 is done" mindset and work going
> forward on that premise.
>

+1

Good luck with that /27 of 1.0.0.0/8 space

At the edge, with the down economy, i bet there are plenty of folks
that are only accept /21s and shorter from their upstream ISP so they
can get some more mileage out of their older gear.

Cameron

Re: Start accepting longer prefixes as IPv4 depletes?

[Cameron Byrne]

On Wed, Dec 8, 2010 at 11:31 AM, Dobbins, Roland  wrote:
>
> On Dec 9, 2010, at 2:10 AM, Mohacsi Janos wrote:
>
>> Do you think adopting LISP or similar architectures to reduce the problems 
>> mentioned above?
>
> Yes.
>

No.  I still fail to see the value of LISP in a mature and sane  IPv6 world.

LISP may have value in a immature and insane IPv4 and IPv6 world.

Cameron

Re: Start accepting longer prefixes as IPv4 depletes?

[Cameron Byrne]

On Wed, Dec 8, 2010 at 11:37 AM, Seth Mattinen  wrote:
> On 12/8/2010 11:23, Cameron Byrne wrote:
>>
>> At the edge, with the down economy, i bet there are plenty of folks
>> that are only accept /21s and shorter from their upstream ISP so they
>> can get some more mileage out of their older gear.
>>
>
> Hopefully they have a default route; ARIN now has PI /24 assignments,
> and none of those would have a large aggregate announcement.
>

Sorry, getting a default route from the provider was assumed  in my
mind and not in the email.  It goes back to routers that can take only
256k routes ... they cant take full tables these days, so they just
ditch the smaller blocks.  The default route still work for
reachability .... but not route optimization at the edge.

Cameron


> ~Seth
>
>

Re: Start accepting longer prefixes as IPv4 depletes?

[Cameron Byrne]

On Wed, Dec 8, 2010 at 11:41 AM, Dobbins, Roland  wrote:
>
> On Dec 9, 2010, at 2:38 AM, Cameron Byrne wrote:
>
>>  I still fail to see the value of LISP in a mature and sane  IPv6 world.
>
> Abstraction of the global routing table away from direct dependence upon the 
> underlying transport in use at a given endpoint network alone offers huge 
> benefits for futureproofing; there are lots of other benefits as well, for 
> mobility, CDNs, and so forth.
>

I believe a lot of folks think the routing paths should be tightly
coupled with the physical topology.  If not, there is MPLS.

If underlying transport is IPv6, i don't see the incremental value
(hence mature IPv6 world comment, most major ISPs are pretty well
along the way).  IP Mobility as in Mobile IP already exists  not
terribly popular.

There is already abstraction within most ISPs with MPLS.  Yet another
layer of abstraction is just not something i would consider lightly
with Internet scale.  Just my humble opinion.

Today, IPv6 provides real value with larger address space.  MPLS
provides real value with FRR and network virtualization (MPLS L3
VPNs).  In a mature IPv6 world, that is sane, i am not sure what the
real value of LISP is.

But, IMHO, i do think there is something to the long term value of
ILNP.  I am just very biased again additional tunnels,
encapsulation/overhead, complexity, and that is what LISP is, edge to
edge tunnels.  Then there is the question of who benefits from LISP
and who pays.  The edge pays and the DFZ guys benefit (they deffer
router upgrades) i already pay the DFZ guys enough today.

Cameron
> ---
> Roland Dobbins  // <http://www.arbornetworks.com>
>
>               Sell your computer and buy a guitar.
>
>
>
>
>
>

Wireless IPv6

[Cameron Byrne]

Folks,

I googled around and could not find anything on this.  Can anyone
share their experience with IPv6 on the Verizon's LTE network?  It is
my understanding that it would be a dual-stack service, but i have not
seen any screenshots or reviews that mention anything about IPv6 at
all from a users perspective.

Cameron

ps.  T-Mobile USA has an IPv6 beta with nokia device http://bit.ly/9s0Ed3
pps.  22 pages of reviews and such focused on the N900 operating with
IPv6 here http://goo.gl/cUUga

Re: Wireless IPv6

[Cameron Byrne]

On Tue, Dec 28, 2010 at 10:15 AM,   wrote:
> On Tue, 28 Dec 2010 12:49:37 EST, Christopher Morrow said:
>
>> on this, I HOPE vzw does the right thing and launches with v4/v6
>> dualstack on the devices in all regions where deployment happens. I
>> don't have much hope that this will actually happen though :(
>
> Personally, I hope they roll it out a region at a time (even a "new time zone
> each day" would probably be good enough), so they can shake the bugs out of
> each region and lower the amount of stress on the network engineers having to
> get *everything* staged at the same time..  Rolling a totally new thing out to
> 100% of the user base on the same day will rarely end well.
>

Just to update the group, a helpful person sent me a screenshot of the
VZW LTE connection manager, and it does indeed have a public IPv6
address an a 10.x.x.x IPv4 address.  So, true to claim, the new LTE
service available today on USB sticks is production dual-stack.
Bravo!

Cameron
==
http://groups.google.com/group/tmoipv6beta
==

Re: Wireless IPv6

[Cameron Byrne]

On Tue, Dec 28, 2010 at 11:04 AM, Joel Jaeggli  wrote:
> On 12/28/10 10:35 AM, Richard Barnes wrote:
>> FWIW, the same does not appear to be true of the Verizon 3G network.  (Not
>> that anyone expected it to be.)  My VZW device has a NATted v4 address and
>> only link-local v6.
>
> lack of a chipset support is a notable problem there

My guess is that VZW 3G will never have IPv6 support.

But, it appears that anything they label as 4G or LTE will be IPv6
enabled on day 0 for all devices designed to operate on that network.
This is a very very good thing, if i understand it correctly.  I also
assume that the 4G devices that have fallen back to 3G network will
not have IPv6 while attached to 3G, only 4G.  The reason i say this is
that VZW is doing all the device management in 4G via IMS, which is
IPv6-only in their implementation. so 4G attached devices must be
v6 to receive management functions, like over the air updates.

The next functional question, is the services on the google whitelist
so that it starts to move some real IPv6 traffic?  The T-Mobile beta
is on the Google whitelist and it makes a big different WRT to real
IPv6 traffic in a meaningful volume being sent on the network

Cameron

>
> joel
>
>> On Dec 28, 2010 1:26 PM, "Cameron Byrne"  wrote:
>>
>> On Tue, Dec 28, 2010 at 10:15 AM,  wrote:
>>> On Tue, 28 Dec 2010 12:49:37 E...
>> Just to update the group, a helpful person sent me a screenshot of the
>> VZW LTE connection manager, and it does indeed have a public IPv6
>> address an a 10.x.x.x IPv4 address.  So, true to claim, the new LTE
>> service available today on USB sticks is production dual-stack.
>> Bravo!
>>
>> Cameron
>> ==
>> http://groups.google.com/group/tmoipv6beta
>> ==
>>
>
>

Re: Problems with removing NAT from a network

[Cameron Byrne]

On Wed, Jan 5, 2011 at 6:42 PM, Dobbins, Roland  wrote:
>
> On Jan 6, 2011, at 9:38 AM, ML wrote:
>
>> At least not without some painful rebuilds of criticals systems which have 
>> these IPs deeply embedded in their configs.
>
> They shouldn't be using IP addresses in configs, they should be using DNS 
> names.  Time to bite the bullet and get this fixed prior to their eventual 
> forced migration to IPv6.
>

Somebody should tell the nytimes.com about this being a bad practice,
many of their images are linked to ip addresses directly and will
certainly fail in the future (this year, mobile) networks that will
use NAT64/DNS64.  I am sure users will find other places to view their
news when nytimes.com fails to work in these ipv6-only networks.

Small summary of the problem of IPv4 literals and how they will break
in certain IPv6 environments that will be deployed this year
http://groups.google.com/group/ipv4literals

Cameron
=
http://groups.google.com/group/tmoipv6beta
=

> 
> Roland Dobbins  // <http://www.arbornetworks.com>
>
> Most software today is very much like an Egyptian pyramid, with millions
> of bricks piled on top of each other, with no structural integrity, but
> just done by brute force and thousands of slaves.
>
>                          -- Alan Kay
>
>
>

Re: Problems with removing NAT from a network

[Cameron Byrne]

On Wed, Jan 5, 2011 at 8:31 PM, Mark Andrews  wrote:
>
> In message , 
> Came
> ron Byrne writes:
>> On Wed, Jan 5, 2011 at 6:42 PM, Dobbins, Roland  wrote:
>> >
>> > On Jan 6, 2011, at 9:38 AM, ML wrote:
>> >
>> >> At least not without some painful rebuilds of criticals systems which ha=
>> ve these IPs deeply embedded in their configs.
>> >
>> > They shouldn't be using IP addresses in configs, they should be using DNS=
>>  names. =A0Time to bite the bullet and get this fixed prior to their eventu=
>> al forced migration to IPv6.
>> >
>>
>> Somebody should tell the nytimes.com about this being a bad practice,
>> many of their images are linked to ip addresses directly and will
>> certainly fail in the future (this year, mobile) networks that will
>> use NAT64/DNS64.  I am sure users will find other places to view their
>> news when nytimes.com fails to work in these ipv6-only networks.
>
> Which is one of the reasons why DS-lite is a better solution for
> providing legacy access to the IPv4 Internet than NAT64/DNS64.
> DS-lite only breaks what NAT44 breaks.  DS-lite doesn't break new
> things.
>

Thanks for the tip.  But, there are legitimate business reason in
various different types of networks for various strategies, thanks for
plugging the one your organization makes.  I am tired of the IPv6
transition flavor of the day war.  The reality for content folks is
that there will be IPv4 host, IPv6 hosts, and dual stack hosts.
Content needs to be dual-stack to reach everyone the best way
(native), but if they lack dual-stack and they use IPv4 literals, they
are going to lose eyeballs. End of story.

Content folks-- do yourself a favor and follow Roland's advice (also
in RFC 1958) and don't use address literals, use names.

And, you will notice that the list at
http://groups.google.com/group/ipv4literals shows only a few web site,
because there are only a few that have this design flaws.  If you know
others, strengthen your case  and add them to the list so that all
parties can benefit.  Otherwise, it is just a few poorly designed
internet services that will be in a rush to fix services when users
complain or there web pages hits start trending down while their
competitors trend up.

Cameron


>> Small summary of the problem of IPv4 literals and how they will break
>> in certain IPv6 environments that will be deployed this year
>> http://groups.google.com/group/ipv4literals
>>
>> Cameron
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>> http://groups.google.com/group/tmoipv6beta
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>> > 
>> > Roland Dobbins  // <http://www.arbornetworks.com>
>> >
>> > Most software today is very much like an Egyptian pyramid, with millions
>> > of bricks piled on top of each other, with no structural integrity, but
>> > just done by brute force and thousands of slaves.
>> >
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Alan Kay
>> >
>> >
>> >
>>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: ma...@isc.org
>

Re: Problems with removing NAT from a network

[Cameron Byrne]

On Wed, Jan 5, 2011 at 9:10 PM, Matthew Kaufman  wrote:
> On 1/5/2011 8:47 PM, Cameron Byrne wrote:
>>
>> And, you will notice that the list at
>> http://groups.google.com/group/ipv4literals shows only a few web site,
>> because there are only a few that have this design flaws.
>
> And the list looks like it does because the list only shows a *few* web
> sites. Other surveys have shown significantly more cases. (
> http://tools.ietf.org/html/draft-wing-behave-http-ip-address-literals-02#appendix-B
> "An examination of Alexa's top 1 million domains [Alexa] at the end of
> August, 2009, showed 2.38% of the HTML in their home pages contained IPv4
> address literals."
>
> And the list looks like is does because the list only shows a few *web
> sites*. Quite a few network protocols, particularly peer-to-peer protocols,

I understand my users pretty well, they only go to a few web pages ...
its the nature of the net.  I assure you, i am not taking any undue
risk with regards to web.  Try our friendly user trial and give me
your feedback, thats why i am running it.

> rely on moving around the IP address literals of peers via mechanisms other
> than DNS. This includes BitTorrent, Adobe's RTMFP, and Skype's proprietary

Ah Skype.  According to your web page you work at Skype.  Skype is a
well known IPv6 spoiler application.  In fact, in the IETF and many
other circles, Skype is the only app that we can't seem to get to work
with IPv6.  Are you here to help with that or to tell us that we need
to keep IPv4 around indefinitely?

In fact, we were just talking about how Skype as a spoiler this morning

 http://www.ietf.org/mail-archive/web/v6ops/current/msg06837.html

Here is a pointer to IPv6-only users who would love to use Skype on
IPv6-only handsets.

http://talk.maemo.org/showthread.php?t=60320&page=24

Looking at the last post, it looks like they were able to NAT46 Skype
to then talk out the NAT64 ... ugly.  But serious, get with me off
list and lets collaborate. I can help from the networks side, and i am
eager to make progress. Skype should not be the IPv6 spoiler app when
NEARLY EVERYTHING ELSE WORKS.  Read the thread i mentioned, real
users, real developers, real network that is IPv6-only.  Notice that
things generally work, those folks have hacked their way to perhaps
even making Skype work.

> protocol, and every VoIP system using STUN and/or ICE, to name just a few.
> Once users figure out that none of those will work when they use you as an
> ISP, they'll find one that's chosen a better transition technology.
>

Seriously, 95+% of my traffic is web and email, and STUN and ICE don't
matter much to grandma as long as m.v6.facebook.com loads.

> Also note that DNSSEC end-to-end and DNS64/NAT64 are mutually exclusive. Now
> that DNSSEC is actually getting some traction, that's just one more reason
> to chose a different way to transition.

Strategy is done.  Implementation is on-going.  3GPP and IETF joint
meeting said dual-stack and IPv6-only + NAT64 are the 2 paths forward
for mobile.

http://www.3gpp.org/ftp/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs./IPW100060.zip

Without going into too much detail, ds-lite does not live in mobile
and likely never will. Any solution that requires IPv4 is not
strategic.  IPv4 addresses simply are not available at the scale of
large mobile network operators, public, private, or bogon.  Mobile
must move to IPv6, and IPv6-only + NAT64 pushes the envelope in ways
that dual-stack never has, and hence it just might work to
*transition* to v6.

As long as dual-stack is around, the app vendors don't have to move
and network guys have to dream up hacks to support these legacy apps
(CGN ).

Cameron

>
> Matthew Kaufman
>

Re: Problems with removing NAT from a network

[Cameron Byrne]

On Wed, Jan 5, 2011 at 9:55 PM, Mark Andrews  wrote:
>
> In message , 
> Came
> ron Byrne writes:
>> As long as dual-stack is around, the app vendors don't have to move
>> and network guys have to dream up hacks to support these legacy apps
>> (CGN ).
>
> NAT64 is CGN expecially when it is being implemented by the cellular
> carriers.
>

Agreed.  And, the NAT44 that 99% of my customer use to today is also a CGN.

It's status quo, all v4 flows require state in my network, NAT44 or NAT64.

But, NAT64 has an exit strategy.  With every new  that comes out,
that is one less destination requiring state in my network.

Cameron


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

Re: Problems with removing NAT from a network

[Cameron Byrne]

On Thu, Jan 6, 2011 at 9:18 AM, Matthew Kaufman  wrote:
> On 1/5/2011 9:39 PM, Cameron Byrne wrote:
>>
>> I understand my users pretty well, they only go to a few web pages ...
>> its the nature of the net.  I assure you, i am not taking any undue
>> risk with regards to web.  Try our friendly user trial and give me
>> your feedback, thats why i am running it.
>
> I'm not particularly surprised that a mobile client platform has a different
> access pattern than desktop users... not a whole lot of mobile BitTorrent
> clients yet, for instance.
>>
>> Ah Skype.  According to your web page you work at Skype.  Skype is a
>> well known IPv6 spoiler application.  In fact, in the IETF and many
>> other circles, Skype is the only app that we can't seem to get to work
>> with IPv6.  Are you here to help with that or to tell us that we need
>> to keep IPv4 around indefinitely?
>
> Indeed, I work at Skype now and Adobe (developing RTMFP) before that.
>
> At this point (because not everyone has IPv6) this class of applications
> (along with BitTorrent and ICE-using VoIP apps) needs to be able to use your
> NAT64 to talk to peers that are IPv4-only. To do that, they need to be able
> to discover your NAT64 even though they're not doing DNS lookups to find the
> IPv4 addresses of peers.
>
> This will take 1) a way to do this and 2) upgrades of the apps to take
> advantage of it. It is impossible to do #2 until #1 is solved.
>
> There's been discussion in BEHAVE about this topic...
> draft-korhonen-behave-nat64-learn-analysis for instance. I even proposed a
> solution that wasn't raised in that or previous documents here:
> http://www.ietf.org/mail-archive/web/behave/current/msg09050.html (which I
> suppose, since it hasn't been mentioned elsewhere, should be written up as a
> draft if/when I have some free time)
>

Skype is not defined in an IETF RFC, so saying you need an RFC to move
forward is bit confusing.  There are several methods that just work
today,

I am all for standards, but a closed platforms generally find ways to
progress without or in spite of standards.  Skype is a closed
platform.

>>  Skype should not be the IPv6 spoiler app when
>> NEARLY EVERYTHING ELSE WORKS.  Read the thread i mentioned, real
>> users, real developers, real network that is IPv6-only.  Notice that
>> things generally work, those folks have hacked their way to perhaps
>> even making Skype work.
>
> There's lots of other apps that don't work. Skype is just the squeaky wheel
> because it is so popular.
>

Please make a list and let us know.  Otherwise, this is just hand
waving like the IPv4 literals sites.  I have had people on various
mailing list tell me all things they think won't work, but in my own
experience and in the experience of my beta users, who are publicly
documenting their efforts on the support boards, things work well.
Yes, some things don't work due the fact that it is a beta and
something don't work due to the fact that it is IPv6-only, but they
are not show stoppers for the business.

As a user, i have been using IPv6-only on Symbian for 9 months without
an issue.  The service works as i would expect it to with IPv4, no
user perceived differences.  Skype is a squeaky wheel, but most  (99%)
things users do works fine.  As mentioned, in mobile, 95+% of the
traffic is web and email.  And, most "apps", are also just web and
email.

My advice to Skype is to come up with a solution to work for IPv6-only
clients. That is my advice to all apps and all content.  IPv6-only
clients are an obvious reality in an IPv4 exhausted world.

You cannot seriously come to a network operators support mailing list
and say that the network guys have to keep investing in network tweaks
while you wait for a standards body to solve a problem for your closed
non-standard applications.

I won't go into my diatribe about why dual-stack is not an obvious
choice in mobile, you can check the video of it at the google IPv6
conference in 2010.  If you have further questions, i am glad to help
you understand and entertain your ideas off list.  The main point is
the dual-stack and substantially more expensive and the IPv4 part of
dual-stack is run out of addressesprivate, public, bogon.

http://www.youtube.com/watch?v=1GlRgaFriYU#t=15m38s

>
>>
>> Seriously, 95+% of my traffic is web and email, and STUN and ICE don't
>> matter much to grandma as long as m.v6.facebook.com loads.
>
> See my above comment about how I'm not surprised, given the specific client
> population.
>>
>> As long as dual-stack is around, the app vendors don't have to move
>> and network guys have to dream up hacks to support these legacy apps
>> (CGN ).
>

Re: Problems with removing NAT from a network

[Cameron Byrne]

ew has acknowledge, and even hinted at
having a better proprietary way.  I am open to new ways and new
partnerships to make this work.  When you are ready to talk about
moving forward, i am all ears.  Until then, you can keep posturing
while the clock ticks on committed  deployments.  If you know it's
coming and don't have a solution, if you strategically choose to play
that game of chicken, thats fine too, it's a calculated risk that my
business has made.

Cameron





> Matthew Kaufman
>
>
>

Re: IPv6 prefix lengths

[Cameron Byrne]

On Jan 12, 2011 7:50 PM, "Richard Barnes"  wrote:
>
> Hi all,
>
> What IPv6 prefix lengths are people accepting in BGP from
> peers/customers?  My employer just got a /48 allocation from ARIN, and
> we're trying to figure out how to support multiple end sites out of
> this (probably around 10).  I was thinking about assigning a /56 per
> site, but looking at the BGP table stats on potaroo.net [1], it looks
> like this is not too common (only .29% of prefixes).  Thoughts?
>

Is it possible you should be using PA space from your ISP? An ISP would have
no issue providing a /48 per site. Not too many details were given about
your requirements or circumstances ... PA may fit.

> Thanks,
> --Richard
>
>
> [1] 
>

Re: NAT-PT or NAT64 in real life

[Cameron Byrne]

On Wed, Jan 19, 2011 at 1:18 AM, jarod smith  wrote:
> Although it would seem that double-stack is still the preferred method of 
> linux
> distribution, I want my next deployed in IPv6 only.
> For linux there is NAT-PT tomicki and NAT64 Viagenie.
>
> I don't have Cisco equipment although I'd like tested their NAT-PT, even if
> it's obsolete.
>

There are some lessons learned here with NAT-PT

http://www.civil-tongue.net/6and4/wiki

But, i would only use NAT-PT for ... no ... i would never use NAT-PT.
The implementations are really not good.

> Are some of you have installed one of these two implementations in
> production on recent versions of linux? Is it stable, secure, ... ?
>

I have tested 3 versions of DNS64 and 4 versions of NAT64.  I am not
sure what i can share about them.  My experience has generally been
good.  I feel good with taking my selected vendors to production with
this feature.  Users in my beta trial have been happy with the results
and performance.  You mentioned Cisco.  Cisco has stateless support
today of NAT64, but i am not sure the value of that since it is one
for one.  I assume they will have stateful support soon.

http://www.cisco.com/en/US/docs/ios/ios_xe/ipaddr/configuration/guide/iad_stateless_nat64_xe.html

aka http://tinyurl.com/4gt9s9y

Juniper has stateful NAT64 today in production code, i have not looked
at this one yet, but it appears promising

http://www.juniper.net/techpubs/en_US/junos10.4/information-products/topic-collections/nce/nat64-ipv6-ipv4-depletion/configuring-nat64-ipv6-ipv4-depletion.pdf

aka http://tinyurl.com/4qxjahk

If you are talking about servers, not users, most of the commercial
load balancers have NAT64 functions for the IPv6 user to IPv4 legacy
server use case.

Cameron
==
http://groups.google.com/group/tmoipv6beta
==

>
> Regards
>

Re: anyone running GPS clocks in Southeastern Georgia?

[Cameron Byrne]

On Jan 21, 2011 6:49 PM, "Pete Carah"  wrote:
>
> On 01/21/2011 04:29 PM, Lamar Owen wrote:
> > On Friday, January 21, 2011 04:23:52 pm Michael Holstein wrote:
> >> Aren't CDMA BTS clocked off GPS?
> > Yep; and many of the aftermarket GPS receivers commonly used for the
disciplined clock for NTP originally came from that service (Agilent/HP
Z3801 and Z3816, for instance).
> Boo.  You can't find the 3816 much anymore and the 3801 isn't as good
> (fine for most ntp purposes,though) (the difference is mostly in
> internal measurement software and how long it will hold without the gps
> signal).
> And Symmetricom bought that line from HP, still sells one comparable to
> the Z3801 but not like the 3816 for a decent price.  Personally I'd
> build one up out of an LPRO, a Trimble timing receiver (current
> replacement for the Oncore used in the
> Z38xx units, last I checked it was under $100), a MSP430 (probably a
> fairly high-end one to get enough program space for a good PLL) and some
> external logic for phase comparators (I don't know if the timer capture
> modes in the 430 are good enough by themselves...)  The most expensive
> single part would be a decent timing antenna (yes, timing antennas *are*
> different from the usual civilian positioning antennas; there is a
> reason why the base is larger diameter than the rest...)
>
> Actually, does anyone still do soft handoff with UMTS?  That was much of

Yes. Providing accurate clock to a cell site is critical for 2/3/4g. This
usually requires a primary (GPS) and backup (1588).

Cb
> the reason why old CDMA needed a GPS reference.
>
> -- Pete
>
>

Re: EPC backhaul networks

[Cameron Byrne]

On Jan 30, 2011 9:03 AM, "Glen Kent"  wrote:
>
> Hi,
>
> I would like to understand why there is a preference for L3 VPNs over
> L2 VPNs for the EPC backhaul networks? We can use both layer 2 and
> layer 3 VPNs for communication between the eNodeB and the MME or S-GW,
> so why is it that most providers prefer L3 over L2.
>

There are just more companies offering L2 metroE than L3 in the backhaul
space.  I have pushed for L3 but very few offer the speeds and reach
required

Cb
> Glen
>

Re: EPC backhaul networks

[Cameron Byrne]

On Jan 30, 2011 10:11 AM, "Mikael Abrahamsson"  wrote:
>
> On Sun, 30 Jan 2011, Cameron Byrne wrote:
>/
>> There are just more companies offering L2 metroE than L3 in the backhaul
space.  I have pushed for L3 but very few offer the speeds and reach
required
>
>
> Could you please elaborate on what you mean by "reach" here?
>
>

The only way to reach 2000 cell sites in Chicago with 100megs of Ethernet
handoff is with L2 metroE.  There is not a feasible L3 service offered
today.

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

Re: EPC backhaul networks

[Cameron Byrne]

On Sun, Jan 30, 2011 at 12:52 PM, Mikael Abrahamsson  wrote:
> On Sun, 30 Jan 2011, Cameron Byrne wrote:
>
>> The only way to reach 2000 cell sites in Chicago with 100megs of Ethernet
>> handoff is with L2 metroE.  There is not a feasible L3 service offered
>> today.
>
> Ah.
>
> We either rent fiber or put up our own radio links, I guess different
> problems in different markets.
>

Yep.  I hate L2.  It is a total nightmare. But, it is literally the
only game in town.  I blame the MEF for spreading propaganda that
MetroEis the best solution for backhaul ... most people dont even
think of L3 solutions all the telcos, cable-cos, and utilities in
this space only do L2  to the cell site even though they all use
the same Juniper and ALU gear that does L3 too ...

Cameron

> --
> Mikael Abrahamsson    email: swm...@swm.pp.se
>

Re: quietly....

[Cameron Byrne]

On Mon, Jan 31, 2011 at 8:38 PM, Owen DeLong  wrote:
> Discussed, Disgusted, and Dismissed.
>
> The E space would take more software upgrades to existing systems than just
> deploying IPv6.
>

It's true.  It was only after discovering how much work it would take
to make 240/4 like RFC 1918 (truly impossible) that I fully engaged in
doing IPv6. Now, we are pretty close to launching an IPv6-only + NAT64
service to mobile customer.

Cameron
===
T-Mobile USA IPv6 Beta -> http://bit.ly/9s0Ed3
===

Re: Using IPv6 with prefixes shorter than a /64 on a LAN

[Cameron Byrne]

On Tue, Feb 1, 2011 at 3:38 PM, Chuck Anderson  wrote:
> On Tue, Feb 01, 2011 at 03:14:57PM -0800, Owen DeLong wrote:
>> On Feb 1, 2011, at 2:58 PM, Jack Bates wrote:
>> > There are many cases where ULA is a perfect fit, and to work
>> > around it seems silly and reduces the full capabilities of IPv6. I
>> > fully expect to see protocols and networks within homes which will
>> > take full advantage of ULA. I also expect to see hosts which don't
>> > talk to the public internet directly and never need a GUA.
>> >
>> I guess we can agree to disagree about this. I haven't seen one yet.
>
> What would your recommended solution be then for disconnected
> networks?  Every home user and enterprise user requests GUA directly
> from their RIR/NIR/LIR at a cost of hunderds of dollars per year or
> more?
>

You might be asking the wrong person for advice or reasoning.

Horses for courses.  ULAs have a place.

Cameron

Re: quietly....

[Cameron Byrne]

On Tue, Feb 1, 2011 at 6:24 PM, Chris Adams  wrote:
> Once upon a time, Owen DeLong  said:
>> On Feb 1, 2011, at 3:41 PM, Karl Auer wrote:
>> > Devil's advocate hat on: NAT (in its most common form) also permits
>> > internal addressing to be independent of external addressing.
>> >
>> Which is a bug, not a feature.
>
> That is an opinion (and not a unversally held opinion), not a fact.  I
> tend to agree with you, but you keep stating your opinion as fact.
> Telling people "I'm right, you're wrong" over and over again leads to
> them going away and ignoring IPv6.
>

+1

Somebody should probably get a blog instead of sending, *39 and
counting*, emails to this list in one day.

Re: RE: So... is it time to do IPv6 day monthy yet?

[Cameron Byrne]

On Jun 14, 2011 10:36 PM, "Ryan Finnesey" <
ryan.finne...@harrierinvestments.com> wrote:
>
> I think this would be helpful.
>

Agreed. You don't need anybody's permission, kick it off.

The last v6day was an isoc effort, there can be a separate nanog effort or
your own.

Cb
> Cheers
> Ryan
>
>
> -Original Message-
> From: Ryan Pavely [mailto:para...@nac.net]
> Sent: Wednesday, June 08, 2011 11:08 AM
> To: nanog@nanog.org
> Subject: Re: So... is it time to do IPv6 day monthy yet?
>
> I was thinking the same thing.  Good call :)
>
>   Ryan Pavely
>Net Access Corporation
>http://www.nac.net/
>
>
> On 6/8/2011 10:40 AM, Jay Ashworth wrote:
> > It certainly sounds like it might be.
> >
> > Cheers,
> > -- jra
> >
>

Re: Consequences of BGP Peering with Private Addresses

[Cameron Byrne]

On Wed, Jun 15, 2011 at 9:47 AM, James Grace  wrote:
> Hey All,
>
> So we're running out of peering space in our /24 and we were considering 
> using private /30's for new peerings.  Are there any horrific consequences to 
> picking up this practice?
>

You can reclaim space by switching your peerings to /31s where possible.

If you go down the private space route, make sure you and your peers
know about "next hop self"

Cameron

Re: Cogent depeers ESnet

[Cameron Byrne]

On Jun 20, 2011 9:47 AM, "Christopher Pilkington"  wrote:
>
> On Jun 20, 2011, at 10:53 AM, Jon Lewis  wrote:
>
> > internet connectivity, and that much $ is at stake, you're stupid if you
don't have some redundancy.  Nothing works all the time forever.
>
> I can't consider Cogent even a redundant link, since I need two other
> upstreams to reach the Internet redundantly.
>

This is the same case I face with level3 today. I have about 5 upstream
isp's and level3 is the only one that does not have a "full ipv6  table" and
therefore sites where level3 is one of the 2 upstreams are not redundant.

I have calls into my account team, the response they gave me was laughable.
 something about how only 0.3% of the internet uses ipv6.

Escalating  if you can, it might be an opportune time for other level3
customers consider an escalation.

Their lack of a full table contributes to the  breakage / risk. This is
not acceptable. Buying from cogent is its own reward, level3 should not be a
service risk in itself.

Cb
> -cjp
>

Re: AS and advertisen questions

[Cameron Byrne]

On Jun 25, 2011 6:04 PM, "Deric Kwok"  wrote:
>
> Hi
>
> Can we use same AS to advertise different networks in different location?
>
> We would like to use Seattle as production network and New York as testing
>
> eg:
> Seattle: network 66.49.130.0/24
>
> New York: network 67.55.129.0/24 and ipv6 network.
>
> Thank you
>

Yes

Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3)

[Cameron Byrne]

On Tue, Jun 28, 2011 at 8:39 AM, Leigh Porter
 wrote:
>
>
>> -Original Message-
>> From: Andreas Ott [mailto:andr...@naund.org]
>> Sent: 28 June 2011 16:27
>> To: Eugen Leitl; williamejs...@googlemail.com
>> Cc: NANOG list
>> Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2
>> (+3)
>>
>> -andreas
>> [who has to explain this about once a week to customers who think
>> that they bought a GigE connection but then can't "ftp" a file from
>> coast to coast at 1Gbps throughput. Use multiple TCP streams!]
>
> Yeah, try explaining to a VSAT customer why they don't get 10Mb/s on their 
> 10Mb/s VSAT connection with a 600ms RTT!
>
> The response is.. "I don't care, I want my 10Mb/s!"...
>

In the 3G world, i have had good results overcoming longish RTT by
using the Hybla TCP algorithm  http://hybla.deis.unibo.it/

I am hoping it gets more default traction, especially in wireless
where the radio link is a pretty big latency source

Cameron

> --
> Leigh
>
>
> __
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> __
>
>

Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3)

[Cameron Byrne]

On Tue, Jun 28, 2011 at 9:11 AM, Leigh Porter
 wrote:
>
>
>> -Original Message-----
>> From: Cameron Byrne [mailto:cb.li...@gmail.com]
>> Sent: 28 June 2011 16:53
>> To: Leigh Porter
>> Cc: Andreas Ott; Eugen Leitl; williamejs...@googlemail.com; NANOG list
>> Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2
>> (+3)
>> In the 3G world, i have had good results overcoming longish RTT by
>> using the Hybla TCP algorithm  http://hybla.deis.unibo.it/
>>
>> I am hoping it gets more default traction, especially in wireless
>> where the radio link is a pretty big latency source
>>
>> Cameron
>
> How do you implement this for lots of clients and servers that have out of 
> the box implementations? The FastSoft box is a TCP man-in-the-middle box that 
> essentially implements the FAST TCP algorithm without either end having to 
> worry about it.
>

You don't, the full benefits only come with a Linux kernel patch.  The
good news is that it only has to be implemented on the client end.

> I have also used home-fudged TCP proxies with some success.
>
> Some 3G/wireless/VSAT vendors implement their own TCP modification stacks but 
> they usually only fiddle with window sizes and such.
>

That's why i said i hope it catches on as default :)  If Android
implemented Hybla, i think it would be a great improvement for user
experience.  Nobody likes the middleboxes that proxy TCP they cost
money, don't scale well, and are generally fragile.  Hybla is not a
solution for the OPs issue, just a solution for high RTT links where
the client can do Hybla.  It an evolutionary step that i think would
make a great fit in smartphones like Android.

Cameron
> --
> Leigh
>
>
> __
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> __
>

Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3)

[Cameron Byrne]

On Tue, Jun 28, 2011 at 1:24 PM, PC  wrote:
> I have found most/all modern 3g networks can achieve optimal download speed
> within their latency limitations (<200ms domestic end-to-end is normal for
> most today) when combined with a modern operating system that does automatic
> TCP receive window adjustments based on per-flow characteristics.  I never
> had a problem getting ~2 megabit from EVDO-revA, and can get ~20 megabit
> without issue from the new Verizon LTE network.  (Windows XP is not modern).
>

AFAIK, Verizon and all the other 4 largest mobile networks in the USA
have transparent TCP proxies in place.

My point was that if end-hosts had Hybla or something similar, these
proxies can be removed providing a better end-to-end solution.

Cameron

> As for VSAT, most every vsat equipment manufacturer has TCP
> acceleration/proxy support built into the satellite modem.  They basically
> forge acks at the hub site to buffer data from the server, then deliver it
> it to the remote end in a continuous flow.  Many also have protocol
> optimizations for some of the more "chatty" protocols.  If you use it, your
> 10 megabit should be achievable for typical HTTP/FTP consumer internet
> activities, and it's surprisingly fast.  I've sustained 6 without issue on
> VSAT, only limited by bandwidth available, doing a simple SCP file transfer.
>
> Of course, none of this is to the scale of transatlantic gigabit transfers
> with a single flow...
>
>
> On Tue, Jun 28, 2011 at 10:16 AM, Cameron Byrne  wrote:
>>
>> On Tue, Jun 28, 2011 at 9:11 AM, Leigh Porter
>>  wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: Cameron Byrne [mailto:cb.li...@gmail.com]
>> >> Sent: 28 June 2011 16:53
>> >> To: Leigh Porter
>> >> Cc: Andreas Ott; Eugen Leitl; williamejs...@googlemail.com; NANOG list
>> >> Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2
>> >> (+3)
>> >> In the 3G world, i have had good results overcoming longish RTT by
>> >> using the Hybla TCP algorithm  http://hybla.deis.unibo.it/
>> >>
>> >> I am hoping it gets more default traction, especially in wireless
>> >> where the radio link is a pretty big latency source
>> >>
>> >> Cameron
>> >
>> > How do you implement this for lots of clients and servers that have out
>> > of the box implementations? The FastSoft box is a TCP man-in-the-middle box
>> > that essentially implements the FAST TCP algorithm without either end 
>> > having
>> > to worry about it.
>> >
>>
>> You don't, the full benefits only come with a Linux kernel patch.  The
>> good news is that it only has to be implemented on the client end.
>>
>> > I have also used home-fudged TCP proxies with some success.
>> >
>> > Some 3G/wireless/VSAT vendors implement their own TCP modification
>> > stacks but they usually only fiddle with window sizes and such.
>> >
>>
>> That's why i said i hope it catches on as default :)  If Android
>> implemented Hybla, i think it would be a great improvement for user
>> experience.  Nobody likes the middleboxes that proxy TCP they cost
>> money, don't scale well, and are generally fragile.  Hybla is not a
>> solution for the OPs issue, just a solution for high RTT links where
>> the client can do Hybla.  It an evolutionary step that i think would
>> make a great fit in smartphones like Android.
>>
>> Cameron
>> > --
>> > Leigh
>> >
>> >
>> > __
>> > This email has been scanned by the MessageLabs Email Security System.
>> > For more information please visit http://www.messagelabs.com/email
>> > __
>> >
>>
>
>

Re: Strange TCP connection behavior 2.0 RC2 (+3)

[Cameron Byrne]

On Jun 29, 2011 6:00 AM, "Ryan Malayter"  wrote:
>
>
>
> On Jun 28, 3:35 pm, Cameron Byrne  wrote:
>
> >
> > AFAIK, Verizon and all the other 4 largest mobile networks in the USA
> > have transparent TCP proxies in place.
>
> Do you have a reference for that information?  Neither AT&T nor Sprint

No.

> seem to have transparent *HTTP* proxies according to
> http://www.lagado.com/tools/cache-test. I would have thought that
> would be the first and most important optimization a mobile carrier
> could make. I used to see "mobile-optimized" images and HTTP
> compression for sites that weren't using it at the origin on Verizon's
> 3G network a few years ago, so Verizon clearly had some form of HTTP
> proxy in effect.
>
> Aside from that, how would one check for a transparent *TCP* proxy? By
> looking at IP or TCP option fingerprints at the receiver? Or comparing
> TCP ACK RTT versus ICMP ping RTT?
>

I am not familiar with that HTTP proxy test.

As I said, they are likely using tcp proxies to get over tcp issues.  I
assume if you were sniffing both ends you could discover changes in
parameters forced by the middle box.

Cb

Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3)

[Cameron Byrne]

On Jun 28, 2011 10:22 PM, "Mikael Abrahamsson"  wrote:
>
> On Tue, 28 Jun 2011, Cameron Byrne wrote:
>
>> My point was that if end-hosts had Hybla or something similar, these
proxies can be removed providing a better end-to-end solution.
>
>
> Well, then you run into the nice problem of the RNCs only having 400
kilobytes of buffers per session and will drop packets if they receive more
packets than that, or sometimes even just because they receive a burst of a
few tens of packets at GigE linerate (because the customer with large TCP
window size is talking to a GigE connected server).
>
> The recommended "solution" from the vendor was to tune the client to a
smaller TCP window size so that their RNC wouldn't get such a large burst.
>
> *sigh*
>

Sounds like a vendor specific issue :(

Good tcp vs default tcp will not close the window tight due to some
ephemeral loss or delay.  The penalties are generally too strong in tcp for
the issues of delay and loss in 3g ... this is one of the main selling
points for tcp proxies  but better done with modern tcp on the clients
instead of a middle box

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

Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3)

[Cameron Byrne]

On Wed, Jun 29, 2011 at 1:48 PM, Mikael Abrahamsson  wrote:
> On Wed, 29 Jun 2011, Cameron Byrne wrote:
>
>> Sounds like a vendor specific issue :(
>
> Absolutely, but this is way too typical for these kinds of networks.
>
>> Good tcp vs default tcp will not close the window tight due to some
>> ephemeral loss or delay.  The penalties are generally too strong in tcp
>> for
>> the issues of delay and loss in 3g ... this is one of the main selling
>> points for tcp proxies  but better done with modern tcp on the clients
>> instead of a middle box
>
> For what kind of devices? I can get full speed (870 kilobyte/s) on 7.2 HSPA
> with single TCP stream on a linux box. Are you referring to handsets that
> get improvement on high latency links?
>

Yes.  Smartphones on UMTS/HSPA have poor bandwidth-delay product,
hence it being common for mobile providers to proxy the TCP to open
windows faster.

Cameron
> --
> Mikael Abrahamsson    email: swm...@swm.pp.se
>

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Cameron Byrne]

On Tue, Jul 12, 2011 at 8:28 AM, Ronald Bonica  wrote:
> Leo,
>
> Maybe we can fix this by:
>
> a) bringing together larger groups of clueful operators in the IETF
> b) deciding which issues interest them
> c) showing up and being vocal as a group in protocol developing working groups
>
> To some degree, we already do this in the IETF OPS area, but judging by your 
> comments, we don't do it nearly enough.
>
> Comments?
>

There may be an OPS area, but it is not listened to.

Witness the latest debacle with the attempt at trying to make 6to4 historic.

Various "non-practicing entities" were able to derail what network
operators largely supported.  Since the IETF failed to make progress
operators will do other things to stop 6to4 ( i have heard no 
over IPv4 transport, blackhole 6to4 anycast, decom relay routers...)

Real network operators have a relatively low BS threshold, they have
customers to support and businesses to run,  and they don't have thumb
wrestle these people who don't actually have any skin in the game.

Cameron


>               Ron
>
>
> -Original Message-
> From: Leo Bicknell [mailto:bickn...@ufp.org]
> Sent: Monday, July 11, 2011 3:35 PM
> To: nanog@nanog.org
> Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
>
> In a message written on Sun, Jul 10, 2011 at 06:16:09PM +0200, Jeroen Massar 
> wrote:
>> Eh ANYBODY, including you, can sign up to the IETF mailing lists
>> and participate there, just like a couple of folks from NANOG are already 
>> doing.
>
> The way the IETF and the operator community interact is badly broken.
>
> The IETF does not want operators in many steps of the process.  If you try to 
> bring up operational concerns in early protocol development for example 
> you'll often get a "we'll look at that later" response, which in many cases 
> is right.  Sometimes you just have to play with something before you worry 
> about the operational details.  It also does not help that many operational 
> types are not hardcore programmers, and can't play in the sandbox during the 
> major development cycles.
>
>
>
>

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Cameron Byrne]

On Tue, Jul 12, 2011 at 8:42 AM, Leo Bicknell  wrote:
> In a message written on Tue, Jul 12, 2011 at 11:28:58AM -0400, Ronald Bonica 
> wrote:
>> Maybe we can fix this by:
>>
>> a) bringing together larger groups of clueful operators in the IETF
>> b) deciding which issues interest them
>> c) showing up and being vocal as a group in protocol developing working 
>> groups
>>
>> To some degree, we already do this in the IETF OPS area, but judging by your 
>> comments, we don't do it nearly enough.
>
> I don't think it's that simple, sadly.  I'll no doubt get flamed
> by the 5 people on NANOG that also participate in the IETF in a
> regular basis, but the reality is most operators don't want to sit
> through multi-year protocol devopment work, or have much of anything
> to do with "pie in the sky" ideas.
>
> The IETF can, should, and does do both of those things today.  Where the
> friction occurs is there is no good place to loop the operators back in,
> so they are often  kicked out, discouraged, or just uninterested on the
> front end (we're going to go play with new ideas kids!) and then not
> brought back in (it's ready for deployment, wait, why are no operators
> interested).
>
> So it's not that individual issues are of interest to operators (outside
> of the IETF OPS area, which is a special case), it's that the process
> needs work.
>
> I'll pick on LISP as an example, since many operators are at least
> aware of it.  Some operators have said we need a locator and identifier
> split.  Interesting feedback.  The IETF has gone off and started
> playing in the sandbox, trying to figure out how to make that go.
> Several years of coding have occured, a bunch of proof of concept
> testing is going on.  Even many of the operators who wanted such a spit
> are not really interested in following the details of the work right
> now.  Of course, if you are, you can, I'm not advocating any exclusions.
>

W.R.T. to LISP,  in defense of the IETF or the IRTF, i do not believe
"the IETF" has told the world that LISP is the best fit for the
Internet or solves any specific problem well.

The IETF has never said the "Internet Architecture" is going to LISP,
and it likely will not / cannot.  My expectation is that LISP will go
away as quickly as it came.

Cameron

> But there is no roadmap in the IETF process now for LISP that says
> "We've got this 90% baked, we need to circulate a draft to the NANOG
> mailing list, request operator comments, and actively solicit operators
> to participate in the expanded test network".  We need that mechanism to
> tell folks "hey, it's real enough your operational feedback is now
> useful" and "come test our new idea".
>
> Today the IETF just finishes their work, "tosses it over the wall" and
> hopes for the best.  Generally it's not 100%, and vendors make
> propretary changes to the standards slowly over time to meet the needs
> of operators.  It would be far better if there was at least one round of
> "ask the operators" and incorproate feedback before it went over the
> wall, and in paricular before working groups disbanded.
>
> In short, make it easy for the operators to participate at the right
> time in the process.  It will be better for everyone!
>
> --
>       Leo Bicknell - bickn...@ufp.org - CCIE 3440
>        PGP keys at http://www.ufp.org/~bicknell/
>
>

Re: best practices for management nets in IPv6

[Cameron Byrne]

On Jul 12, 2011 2:33 PM, "Tom Ammon"  wrote:
>
> Hi All,
>
> We're pushing to get IPv6 deployed and working everywhere in our
operation, and I had some questions about best practices for a few things.
>
> On your management nets (network device management nets) , what's the best
approach for addressing them? Do you use ULA? Or do you use  global
addresses and just depend on router ACLs to protect things? How close are we
to having a central registry for unique local addresses, and will that
really happen?
>

ACL are prone to typos and inconsistent deployment. If the security policy
is that a give interface must not talk to the internet, ULA is a good choice
as part of a multi-layer security strategy

Cb
> Tom
>
>
-
> Tom Ammon
> Network Engineer
> M: (801)674-9273
> tom.am...@utah.edu
>
> Center for High Performance Computing
> University of Utah
> http://www.chpc.utah.edu
>
-
>
>

Re: in defense of lisp (was: Anybody can participate in the IETF)

[Cameron Byrne]

On Jul 12, 2011 5:21 PM, "Randy Bush"  wrote:
>
> > W.R.T. to LISP,  in defense of the IETF or the IRTF, i do not believe
> > "the IETF" has told the world that LISP is the best fit for the
> > Internet or solves any specific problem well.
> >
> > The IETF has never said the "Internet Architecture" is going to LISP,
> > and it likely will not / cannot.  My expectation is that LISP will go
> > away as quickly as it came.
>
> i will not dispute this, not my point.  but i have to respect dino and
> the lisp fanboys (and, yes, they are all boys) for actually *doing*
> something after 30 years of loc/id blah blah blah (as did hip).  putting
> their, well dino's, code where their mouths were and going way out on a
> limb.
>

Understood. But watch for similarities between 6to4 and LISP. Both are
clever, both have great intentions, both are extremely dangerous once people
start thinking this is anything beyond a toy.  And when lowly plebeians like
myself hear that research folks at iij and Facebook are doing "something"
with LISP, we think that is a blessing of this technology. But, after the
"fan boy" chatter dies down, you hear that this is not actually support,
it's just engineers doing "Dino" a favor.

I admittedly have dismissed LISP early on and do not understand its merits ,
the idea of ip in ip tunnels as the new internet architecture gives me
indigestion.  I am also concerned about  the questionable business case of
why edge networks would make investments to bail out DFZ providers (the main
point of LISP).  If ipv6 was a hard sell, I can't even imagine making LISP
get traction. If the economics are not right, it will never fly, and the
economics of LISP are all wrong. Please, spare me line about how LISP is
just a knob I turn and has no cost.

I fear that at its worst and most successful, LISP ensures ipv4 is the
backbone transport media to the detriment of ipv6 and at its best, it is a
distraction for folks that need to be making ipv6 work, for real.

Cb

PS. I think the research guys should give more time to ILNP and creating a
graceful unwind of ipv4 and NAT.  The dividends from ipv6 only start to
really pay when ipv4 becomes optional. My 2 cents, and no more.

> i am *not* saying i would run it in an operational network.  but maz-san
> and i were happy to help the experiment by dropping the first asian node
> in a test rack on the public net.
>
> randy

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[Cameron Byrne]

On Jul 12, 2011 6:42 PM, "Mark Andrews"  wrote:
>
>
> In message <56e0fb8f-bb53-4db0-829b-39dfbab48...@bogus.com>, Joel Jaeggli
write
> s:
> >
> > On Jul 12, 2011, at 12:53 PM, Owen DeLong wrote:
> >
> > >=20
> > > On Jul 12, 2011, at 8:43 AM, Cameron Byrne wrote:
> > >=20
> > >> On Tue, Jul 12, 2011 at 8:28 AM, Ronald Bonica 
=
> > wrote:
> > >>> Leo,
> > >>>=20
> > >>> Maybe we can fix this by:
> > >>>=20
> > >>> a) bringing together larger groups of clueful operators in the IETF
> > >>> b) deciding which issues interest them
> > >>> c) showing up and being vocal as a group in protocol developing =
> > working groups
> > >>>=20
> > >>> To some degree, we already do this in the IETF OPS area, but judging
=
> > by your comments, we don't do it nearly enough.
> > >>>=20
> > >>> Comments?
> > >>>=20
> > >>=20
> > >> There may be an OPS area, but it is not listened to.
> > >>=20
> > >> Witness the latest debacle with the attempt at trying to make 6to4 =
> > historic.
> > >>=20
> > >> Various "non-practicing entities" were able to derail what network
> > >> operators largely supported.  Since the IETF failed to make progress
> > >> operators will do other things to stop 6to4 ( i have heard no 
> > >> over IPv4 transport, blackhole 6to4 anycast, decom relay routers...)
> > >>=20
> > > Those are all REALLY bad ideas. Speaking as an operator, the best =
> > thing you
> > > can do to alleviate the problems with 6to4 is operate more, not less =
> > 6to4
> > > relays.
> >
> > Unless of course the large providers get their shared transition space =
> > in which case all 6to4 behind it will break in a really ugly way, pretty
=
> > much exactly like in the mobile operator in question.=20
>
> And would deploying draft-andrews-v6ops-6to4-router-option-02.txt and/or
> adding router reachability tests have addressed this issue?
>
> > The goal of 6to4 to historic was not to encourage the outcome described,
=
> > it was to take having 6to4 as a default method of any kind off the table
=
> > going into the future. If mature adults want to use it great, but =
> > conformance tests shouldn't require it, CPE shouldn't it on just because
=
> > what they think they have a is a public IP with not filtering and hosts
=
> > shouldn't use it unless told to do so..
>
> But that is *not* what the draft did.  Making the protocol historic
> did LOTS more than that.  I think there was universal consensus
> that 6to4 should be off by default.
>
> There was this nuke 6to4 from orbit attitude which did nothing to
> help with already deployed/shipped boxes.  6to4 historic is actually
> harmful for dealing with the existing problems as it tells vendors
> not to include 6to4 support in future products which means operators
> won't have boxes with fixes to other problems to alleviate the
> problems cause but the currently deployed customer boxes.
>
> What would have been much better would have been to encourage CPE
> vendors to release images which address some of the known issues.
> Just adding a check box saying "enable 6to4" and for ISP to send
> out email to say "check your router vendor web site for fixed
> images".  The better fix would be to get them to also add support
> for draft-andrews-v6ops-6to4-router-option-02.txt which greys out
> the checkbox when 0.0.0.0 is sent as a response to the option.
>
> Remember operators are in the position to alleviate lots of the
> 6to4 issues themselves.
>

But they will not. If there is not a revenue forecast, there is no project.
That said, CGN is moving forward as a "keep the lights on" initiative as
is real native v6.

I don't care to rehash this yet again with no progress.

Cb.
> > > Blocking  over IPv4 transport is just silly. It's just as likely =
> > that your
> > >  record is destined for an end-host that has native IPv6 =
> > connectivity
> > > with an intermediate resolver that desn't have IPv6 as it is that =
> > you're
> > > sending that to a 6to4 host. Further, there's no reason to believe the
> > > 6to4 host won't attempt to resolve via IPv6, so, it doesn't really =
> > help
> > > anyway.
> > >=20
> > >> Real network operators have a relatively low BS threshold, they have
> > >> c

Re: in defense of lisp (was: Anybody can participate in the IETF)

[Cameron Byrne]

On Jul 13, 2011 7:39 AM, "Scott Brim"  wrote:
>
> On Wed, Jul 13, 2011 at 10:09, Randy Bush  wrote:
> > btw, a litte birdie told me to take another look at
> >
> > 6296 IPv6-to-IPv6 Network Prefix Translation. M. Wasserman, F. Baker.
> > June 2011. (Format: TXT=73700 bytes) (Status: EXPERIMENTAL)
> >
> > which also could be considered to be in the loc/id space
> >
> > randy
>
> No, that's a misuse of "loc/id" since no identification is involved,
> even at the network layer -- but it is in the "reduce issues in global
> routing and local renumbering" space (that's part of what LISP does).
>
> Cameron: As for ILNP, it's going to be difficult to get from where
> things are now to a world where ILNP is not just useless overhead.
> When you finally do, considering what it gives you, will the journey
> have been worth it?  LISP apparently has more benefits, and NPT6 is so
> much easier -- particularly if you have rapid adaptation to apparent
> address changes, which many apps have and all mobile devices need
> already -- sorry but I don't think ILNP is going to make it.  You
> can't just say "the IETF should pay more attention".  I've invited
> people to promote it and nobody stepped up.
>

"Difficult" depends on your time horizon. Ipv6 is/was difficult. Sctp is
difficult, but I remain bullish on its value. ILNP may be more difficult,
but i believe it is strategically correct.

We can disagree on merits of competing RESEARCH  topics. I am just providing
"ops feedback ", to bring this thread full circle.

Lastly, we must make sure that LISP does not become the next 6to4 where good
intentions for RESEARCH  become a quantifiable network nightmare.

Cb

Re: in defense of lisp

[Cameron Byrne]

On Jul 13, 2011 7:50 AM, "Seth Mos"  wrote:
>
> Op 13-7-2011 16:09, Randy Bush schreef:
> > > btw, a litte birdie told me to take another look at
>
> The free Open Source FreeBSD based pfSense firewall supports this. Not
> everyone can get BGP, specifically calling out residential connections
here.
>
> As a 1:1 NAT mechanism it works pretty well, I can reach the outside,
> and the outside can reach me. Which I think is what was intended in the
> specifications. And pretty much the internet.
>
> It took me 4 months to write the IPv6 support in pfSense to what it is
> today. Which is not feature complete. But the NPT part was just a few
> hours in the grand scheme.
>
> I've also contacted the nice people from the draft that we support it.
>
> Since then we've got v4 and v6 with BGP at work so it's moot. But I
digress.
>
> Kind regards,
>
> Seth Mos
> pfSense developer.
>
>

Thank you for your work.

CB

> > >
> > > 6296 IPv6-to-IPv6 Network Prefix Translation. M. Wasserman, F. Baker.
> > >  June 2011. (Format: TXT=73700 bytes) (Status: EXPERIMENTAL)
> > >
> > > which also could be considered to be in the loc/id space
> > >
> > > randy
> > >
> > >
>

Re: OOB

[Cameron Byrne]

On Jul 26, 2011 6:57 AM, "harbor235"  wrote:
>
> I am curious what is the best practice for OOB for a core
> infrastructure environment. Obviously, there is
> an OOB kit for customer managed devices via POTS, Ethernet, etc ... And
> there is OOB for core infrastructure
> typically a separate basic network that utilizes diverse carrier and
diverse
> path when available.
>
> My question is, is it best practice to extend an inband VPN throughout for
> device management functions as well?
> And are all management services performed OOB, e.g network management,
some
> monitoring, logging,
> authentication, flowdata, etc . If a management VPN is used is it also
> extended to managed customer devices?
>
> What else is can be done for remote management and troubleshooting
> capabilities?
>

IMHO, it is always a good idea to have completely different infrastructure
supporting Oob. It is the only way you can recover remotely from many types
of network errors. If the router is hung at rommon, somebody has to get on
console  or accidentally removes your igp instanance ...

But, the business criticality of the network needs to justify the cost
(dial, DSL, 3rd party L3 vpn )

Cb
> Mike

Re: dynamic or static IPv6 prefixes to residential customers

[Cameron Byrne]

On Jul 26, 2011 7:58 AM, "JORDI PALET MARTINEZ" 
wrote:
>
> Hi all,
>
> I will like to know, from those deploying IPv6 services to residential
> customers, if you are planning to provide static or dynamic IPv6 prefixes.
>
> Just to be clear, I'm for static prefix delegation to residential
> customers, however I heard that some ISPs are doing dynamic delegations,
> the same way as is common today with IPv4.
>
> I don't thin it make sense, as the main reason for doing so in IPv4 was
> address exhaustion and legacy oversubscription models such as PPP/dial-up.
>

In mobile, v6 addresses will be dynamic with no persistence across link
state changes.

Cb

> Regards,
> Jordi
>
>
>
>
>
>
> **
> 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 use of the
individual(s) named above. If you are not the intended recipient be aware
that any disclosure, copying, distribution or use of the contents of this
information, including attached files, is prohibited.
>
>
>
>

Re: dynamic or static IPv6 prefixes to residential customers

[Cameron Byrne]

On Tue, Jul 26, 2011 at 9:11 AM, JORDI PALET MARTINEZ
 wrote:
> Hi Cameron,
>
> What about routers ? In some locations, users may have only the choice of
> cellular broadband instead of DSL, cable or fiber.
>

>From an architectural perspective, mobile broadband routers are
treated the same and can expect only ephemeral address assignments.
This is the general case for generic mobile devices accessing the
internet, there can be specific arrangements for specific industrial
use cases (this traffic signal/ gas meter/ windmill always gets this
address).

Cameron

> Regards,
> Jordi
>
>
>
>
>
>
> -Mensaje original-
> De: Cameron Byrne 
> Responder a: 
> Fecha: Tue, 26 Jul 2011 08:34:36 -0700
> Para: Jordi Palet Martinez 
> CC: NANOG list 
> Asunto: Re: dynamic or static IPv6 prefixes to residential customers
>
>>
>>On Jul 26, 2011 7:58 AM, "JORDI PALET MARTINEZ"
>> wrote:
>>>
>>> Hi all,
>>>
>>> I will like to know, from those deploying IPv6 services to residential
>>> customers, if you are planning to provide static or dynamic IPv6
>>>prefixes.
>>>
>>> Just to be clear, I'm for static prefix delegation to residential
>>> customers, however I heard that some ISPs are doing dynamic delegations,
>>> the same way as is common today with IPv4.
>>>
>>> I don't thin it make sense, as the main reason for doing so in IPv4 was
>>> address exhaustion and legacy oversubscription models such as
>>>PPP/dial-up.
>>>
>>In mobile, v6 addresses will be dynamic with no persistence across link
>>state changes.
>>Cb
>>> Regards,
>>> Jordi
>>>
>>>
>>>
>>>
>>>
>>>
>>> **
>>> 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 use of the
>>>individual(s) named above. If you are not the intended recipient be
>>>aware that any disclosure, copying, distribution or use of the contents
>>>of this information, including attached files, is prohibited.
>>
>>>
>>>
>>>
>>>
>>
>
>
>
> **
> 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 use of the 
> individual(s) named above. If you are not the intended recipient be aware 
> that any disclosure, copying, distribution or use of the contents of this 
> information, including attached files, is prohibited.
>
>
>
>
>

Re: IPv6 end user addressing

[Cameron Byrne]

On Aug 6, 2011 2:11 AM, "Owen DeLong"  wrote:
>
> I'm not the only person who prefers /48 and hopefully most ISPs will
eventually
> come around and realize that /56s don't really benefit anyone vs. /48s.
>
> Hurricane Electric has been handing out /48s upon request to our customers
and
> users of our IPv6 tunnel services. We do not anticipate changing that
policy.
>
> Owen
>

A lot of good that /48 will do while HE rides out their on going peering war
and customers are missing a wide swath of the ipv6 routing table.

Cb

> On Aug 5, 2011, at 3:56 PM, Frank Bulk wrote:
>
> > Let's clarify -- /48 is much preferred by Owen, but most ISPs seem to be
> > zeroing in on a /56 for production.  Though some ISPs are using /64 for
> > their trials.
> >
> > Frank
> >
> > -Original Message-
> > From: Owen DeLong [mailto:o...@delong.com]
> > Sent: Friday, August 05, 2011 12:21 PM
> > To: Brian Mengel
> > Cc: nanog@nanog.org
> > Subject: Re: IPv6 end user addressing
> >
> > /56 is definitely preferable to /64, but, /48 really is a better choice.
> >
> > /56 is very limiting for autonomous hierarchical deployments.
> >
> > It's not about number of subnets. It's about the ability to provide some
> > flexibility
> > in the breadth and depth of bit fields used for creating hierarchical
> > topologies
> > automatically.
> >
> > Owen
> >
> > On Aug 5, 2011, at 9:17 AM, Brian Mengel wrote:
> >
> >> In reviewing IPv6 end user allocation policies, I can find little
> >> agreement on what prefix length is appropriate for residential end
> >> users.  /64 and /56 seem to be the favorite candidates, with /56 being
> >> slightly preferred.
> >>
> >> I am most curious as to why a /60 prefix is not considered when trying
> >> to address this problem.  It provides 16 /64 subnetworks, which seems
> >> like an adequate amount for an end user.
> >>
> >> Does anyone have opinions on the BCP for end user addressing in IPv6?
> >
>

Re: US internet providers hijacking users' search queries

[Cameron Byrne]

On Aug 8, 2011 4:24 PM, "Christopher Morrow" 
wrote:
>
> On Sat, Aug 6, 2011 at 10:03 PM, Scott Helms 
wrote:
> > Not trying to be obtuse, but none of the technical docs you cite appear
to
> > talk about HTTP proxies nor does the newswire report have any technical
> > details.  I have tested several of the networks listed in the report and
in
> > none of the cases I saw was there HTTP proxy activity.  Picking up on
> > WCCP/TCS isn't that hard (I used to install those myself) so unless
there is
> > some functionality in IOS and/or JUNOS that allows I don't see it
happening.
> >  Paxfire can operate all of the proxies they want but the network
> > infrastructure has to be able to pass the traffic over to those proxies
and
> > I don't see it (on at least 3 of the networks cited).
>
> barefruit/paxfire/nominum/etc all do essentially the same thing:
> 1) install a dns-appliance in-line (some form of in-line, there are
> lots of options, it's not really important in the end which is used)
> between 'cache resolver' and 'user'. (198.6.1.1 has a paxfire
> appliance literally in-line between it's customer facing port and the
> world)
>
> 2) chose a set/subset of queries to falsify answers for (nxdomain
> only? autosearch.msn.com? *.google.com? *?)
>
> 3) run a farm of servers somewhere else (in the case of paxfire they
> are the jomax.net servers:
>  ;; QUESTION SECTION:
> ;asdkjad912jd.123adsad.com. IN  A
> ;; ANSWER SECTION:
> asdkjad912jd.123adsad.com. 60   IN  A   64.158.56.49
> asdkjad912jd.123adsad.com. 60   IN  A   63.251.179.49
> ;; AUTHORITY SECTION:
> asdkjad912jd.123adsad.com. 65535 IN NS  WSC2.JOMAX.NET.
> asdkjad912jd.123adsad.com. 65535 IN NS  WSC1.JOMAX.NET.
>
>  In the case of barefruit it's another complex and in the case of
> nominum it's a third complex ...
>
> 4) accept http/https/etc on the complex of servers, funnel you an
> answer which is essentially 'hostname == search-query'. For non-http
> most of these complexes are SUPPOSED to not permit a connect to
> happen... for jomax at least they don't accept tcp/443, they do accept
> 25 though :(
>
> 5) profit if users click on these results.
>
> It's not black magic, it's annoying and wrong for some versions
> (depending upon your ethics I guess?) of wrong :( I wish ISP's would
> stop doing this, and it seems that some folk have luck twisting arms
> at ISP's to make this stop.
>
> -chris
>

Some people believe the search results are a better user experience than the
error page they would otherwise receive.  The "awesome bar" is a similar
featureimho

Cb

Re: IPv6 end user addressing

[Cameron Byrne]

On Aug 10, 2011 7:45 PM, "Mark Newton"  wrote:
>
>
> On 11/08/2011, at 8:42 AM, Owen DeLong wrote:
> >
> > I suppose that limiting enough households to too small an allocation
> > will have that effect. I would rather we steer the internet deployment
> > towards liberal enough allocations to avoid such disability for the
> > future.
>
>
> I see the lack of agreement on whether /48 or /56 or /60 is good for a
> home network to be a positive thing.
>
> As long as there's no firm consensus, router vendors will have to
implement
> features which don't make silly hard-coded assumptions.
>
> Innovation will still happen, features will still be implemented, we'll
> still climb out of the NAT morass.  But we'll do it with CPE that allows
for
> a richer spectrum of variation than we would if we just said, "Dammit, /48
for
> everyone."
>
> It's all good.  At this stage of the game, any amount of "moving forward"
is
> better than staying where we are.
>
> (which reminds me: http://www.internode.on.net/news/2011/08/238.php It
ain't
> that hard)
>

Finally a useful post in this thread.  Good work on the deployment of real
ipv6!

Cb

>  - mark
>
> --
> Mark Newton   Email:  new...@internode.com.au(W)
> Network Engineer  Email:  new...@atdot.dotat.org (H)
> Internode Pty Ltd Desk:   +61-8-82282999
> "Network Man" - Anagram of "Mark Newton"  Mobile: +61-416-202-223
>
>
>
>
>
>

Re: IPv6 end user addressing

[Cameron Byrne]

On Aug 11, 2011 5:25 PM, "Owen DeLong"  wrote:
>
>
> On Aug 11, 2011, at 5:08 PM, Matthew Moyle-Croft wrote:
>
> >
> > On 11/08/2011, at 1:33 PM, Owen DeLong wrote:
> >
> >>
> >> On Aug 10, 2011, at 7:45 PM, Mark Newton wrote:
> >>
> >>>
> >>> On 11/08/2011, at 8:42 AM, Owen DeLong wrote:
> 
>  I suppose that limiting enough households to too small an allocation
>  will have that effect. I would rather we steer the internet
deployment
>  towards liberal enough allocations to avoid such disability for the
>  future.
> >>>
> >>>
> >>> I see the lack of agreement on whether /48 or /56 or /60 is good for a
> >>> home network to be a positive thing.
> >>>
> >>> As long as there's no firm consensus, router vendors will have to
implement
> >>> features which don't make silly hard-coded assumptions.
> >>>
> >> Yes and no. In terms of potential innovations, if enough of the market
chooses
> >> /60, they will hard code the assumption that they cannot count on more
than
> >> a /60 being available into their development process regardless of what
> >> gets into the router. Sure, they won't be able to assume you can't get
a /48,
> >> but, they also won't necessarily implement features that would take
advantage
> >> of a /48.
> >
> >
> > Abundance doesn't drive innovations.  Scarcity does.  IPv6 does not have
a scarcity issue.  I assert that IPv6 addressing is not going to now or ever
do anything particularly innovative that can't be done better at other, more
relevant, layers.
> >
>
> Abundance won't drive innovation, but, scarcity can block it.
>
> If enough providers limit their residential customers to /60s, then, that
will become the defining limit to which vendors implement.
>
> > The time for arguing about arbitrary things that make no difference to
the end customers has passed.  The navel gazing must cease and we must move
forward on IPv6 to the home rather than continuing the confusion about this
and other IPv6 arbitrary bit obsession stuff.
> >
>
> On that I believe we are in complete agreement. Let's deploy IPv6 to end
users and give them /48s and move on.
>
> > We need to stop spending our time on rearranging the Titanic's
deckchairs and get the  on with stopping the crashing into the
iceberg by providing clear leadership on getting IPv6 to the masses to
enable their APPLICATIONS and EXPERIENCE without the impending doom of IPv4
CGN.
> >
>
> Again, no argument.
>
> > My name is Matthew, I HAVE given my customers the ability to get IPv6
and I don't give a flying one about the prefix length, I care about getting
ANY prefix to the end users so they can use it and solve the issues at their
end.  I AM enabling innovation just by doing that.
> >
>
> My name is Owen. I work for an ISP that gives IPv6 to our customers and
anyone else who cares to connect.
>
> We care about prefix length because we believe it will impact innovation
for many years.
>
> Yes, getting something to end users is more important than how big of a
prefix we give them. On that, MMC and I are in complete agreement.
>
> However, there are choices to be made in how we do it and giving out /48s
costs virtually nothing and yields real potential benefits. There
> is no meaningful advantage to placing arbitrary limits below /48 on
residential customers.
>

I agree that this debate  is confusing people and will not be solved here.
Let's move on to a more productive topic. There is more than one way to
deploy ipv6. Do what's right for your own users and network.

Cb
> Owen
>
>

RE: Verizon Business - LTE?

[Cameron Byrne]

On Aug 12, 2011 8:40 PM, "Ryan Finnesey"  wrote:
>
> Well they are two completely separate companies .  I would think that the
> LTE network would be a good replacement for DS1 type services.
>

My guess is no.

Yes, I bet vzw buys from vzb, but not the other way round. Whatever you call
the vz LEC does not want to give 40 some cents on the dollar to Vodafone ...
the other part of the vzw ownership.

Not to mention that LTE is an IP service and ds1 is tdm...

Cb

> -Original Message-
> From: Charles N Wyble [mailto:char...@knownelement.com]
> Sent: Friday, August 12, 2011 11:26 PM
> To: nanog@nanog.org
> Subject: Re: Verizon Business - LTE?
>
> On 08/12/2011 10:23 PM, Ryan Finnesey wrote:
> > Does anyone know if Verizon Business is using the Verizon Wireless LTE
> > network to deliver service?
>
> Who else would they use? I would presume they are eating their own dog
food.
> If not, that's very sad. :)
>
>
>
>
>

Re: IPv6 Real World Maturity (was re: How long is your rack?)

[Cameron Byrne]

On Aug 15, 2011 2:15 PM, "Tim Wilde"  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 8/15/2011 2:24 AM, Owen DeLong wrote:
> > What does it say that the same thing happens in IPv4?
> >
> > I really don't see a significant difference in that regard.
>
> I will admit to not having run the numbers and trying to compare IPv4
> protocol-specific discussion threads vs. IPv6, but it certainly "feels"
> like there are more.  My feeling is also that the IPv6 discussions are
> much more fundamental, in that they're discussing basic deployment
> strategies, etc.  But it could all be selection bias because it's
> prominent in the collective mindset, I'll grant you that.
>

Yes, selection bias. There are some people who like to talk about basic
things, state their opinions as facts, and email a lot.

I keep trying to come up with a religion analogy, but none are just quite
right. Did Copernicus hang around at the Vatican to talk about Heliocentrism
?

Cb
> > Yes, IPv6 is currently a little less fully baked than IPv4. IPv4 is
> > 20 years older than IPv6, so I say that's to be somewhat expected.
>
> Point taken.  Anyone have time to try to do a long-term comparative
> study of discussions on deployment strategies and things like NAT, DHCP,
> etc, for IPv4 vs. IPv6, factoring in the differing levels of overall
> Internet adoption at the time of IPv4 adoption vs. IPv6, etc?  If so, I
> have a few other tasks I'd love to have you do... :)
>
> As others have said, I guess what it really shows is that nothing ever
> really changes, and no one (protocol designers, IETF folks, operators,
> router vendors, etc) is perfect, despite our best efforts to be. :)
>
> Regards,
> Tim
>
> - --
> Tim Wilde, Senior Software Engineer, Team Cymru, Inc.
> twi...@cymru.com | +1-630-230-5433 | http://www.team-cymru.org/
> -BEGIN PGP SIGNATURE-
>
> iEYEARECAAYFAk5JjEYACgkQluRbRini9thaIwCggaprPoquYDvQ3b4Pp53qfe43
> KlAAoIWjjr5ItnWdMcIOW7Fc9rvbPRfw
> =M9lE
> -END PGP SIGNATURE-
>

Re: Verizon Business - LTE?

[Cameron Byrne]

On Aug 16, 2011 9:41 AM,  wrote:
>
> On Tue, 16 Aug 2011 10:53:24 EDT, Christopher Morrow said:
>
> > anyway, they do these donkey things because they can :( people have no
> > real option (except not to play the game, ala war games).
>
> My brother recently tried to get a smartphone without a data plan (as the
> phone he wanted was also Wifi-capable, and he was *quite* willing to be
able
> to do data-type stuff only when in range of an access point because he's
in
> range of one 95% of the time he'd want to use data features).  But at
least
> one vendor said they wouldn't activate a phone under those conditions.
>
> Anybody got a good pairing of Android-based smartphone and vendor willing
> to play that game?
>

If you pay full price for the phone, this should not be an issue. Many
carriers price in data plans to offset the handset hardware subsidy.

I would recommend the unlocked nexus s with a prepaid sim for voice minutes
... and wifi for data only. Really, any phone you buy free and clear without
subsidy and contract should work fine as a phone with a prepaid sim

Re: OSPF vs IS-IS

[Cameron Byrne]

On Aug 17, 2011 6:58 AM, "Justin M. Streiner" 
wrote:
>
> On Wed, 17 Aug 2011, Randy Bush wrote:
>
>>> What would you rather rely on at 3am in the morning when things are
>>> breaking?  Someone who has just learned IS-IS or someone who already
>>> has good experience with OSPF?
>>
>>
>> what would you rather rely on at three in the morning when things are
>> breaking, someone who has just learned OSPF or someone who already
>> has good experience with IS-IS?
>>
>> this seems a silly reversal until you realize that OSPF is significantly
>> more complex and thus harder.
>
>
> And if the person who is involved at 3 AM is well versed in OSPF, this all
becomes a non-issue.
>

And if the person at 3am . no.

What's sad is that there are only 2 real options and they are both imperfect
yet there is really no innovation I know of going on in this area

Cb

> jms
>

Re: LISP/ILNP/RFC6296 - what do you want?

[Cameron Byrne]

On Sat, Aug 20, 2011 at 2:37 PM, Daniel Roesen  wrote:
> On Sat, Aug 20, 2011 at 01:57:36PM -0700, Randy Bush wrote:
>> as you can see, i am interested in
>>   o loc/id separation
>>   o rounting table scaling
>>   o deployability on the internet
>>   o current state of development
>>
>> what did i miss?  what major attributes interest you?
>
> o Trust model (how much trust is put in whom so that connectivity works)
> o How much state where
> o Security implications (where are the weak links, vectors for attack)
> o Traffic engineering (ingress and egress) features
> o Session survivability on rerouting (manual and due to outages)
>

- complexity (define a metric [eek!] ...)
- overhead (who, what, where, why..[closely tied with the "state" question])
- who benefits and who pays?  endpoints?  backbones ISPs in the DFZ?
SMB?  Enterprises?  Router companies? ... it's like Lenin said, you
look for the person who will benefit and...

Re: NAT444 or ?

[Cameron Byrne]

On Thu, Sep 1, 2011 at 11:36 AM, Serge Vautour  wrote:
> Hello,
>
> Things I understand: IPv6 is the long term solution to IPv4 exhaustion. For 
> IPv6 to work correctly, most of the IPv4 content has to be on IPv6. That's 
> not there yet. IPv6 deployment to end users is not trivial (end user support, 
> CPE support, etc...). Translation techniques are generally evil. IPv6->IPv4 
> still requires 1 IPv4 IP per end user or else you're doing NAT. IPv4->IPv6 
> (1-1) doesn't solve our main problem of giving users access to the IPv4 
> Internet.
>

Correct, all content is not there yet... but World IPv6 Day showed
that Google, Facebook, Yahoo, Microsoft and 400+ others are just about
ready to go.

http://en.wikipedia.org/wiki/World_IPv6_Day

IPv6->IPv4 does not require 1 to 1,  any protocol translation is a
form of NATish things, and stateful NAT64 has many desirable
properties IF you already do NAT44.  Specifically, it is nice that
IPv6 flows bypass the NAT  and as more content becomes  IPv6, NAT
becomes less and less used.  In this way, unlike NAT44 or NAT444,
NAT64 has an exit strategy that ends with proper E2E networking with
IPv6... the technology and economic incentives push the right way
(more IPv6...)

Have a look at http://tools.ietf.org/html/rfc6146

There are multiple opensource and big vendor (C, J, B, LB guys...)
implementation of NAT64 / DNS64 ... I have trialed it and plan to
deploy it, YMMV... It works great for web and email, not so great for
gaming and Skype.

>
> I expect like most companies we're faced with having to extend the life of 
> IPv4 since our users will continue to want access to the IPv4 content. Doing 
> that by giving them an IPv6 address is not very feasible yet for many 
> reasons. NAT444 seems like the only solution available while we slowly 
> transition over to IPv6 over the next 20 years. Based on the this RFC, NAT444 
> breaks a lot of applications!
>
> http://tools.ietf.org/html/draft-donley-nat444-impacts-01
>

This is just putting IPv4 on life support without moving needle
towards a long term solution. NAT64 = good investment to get IPv6 off
the blocks.  NAT444 = life support / money pit with forklift exit
required.

> Has anyone deployed NAT444? Can folks share their experiences? Does it really 
> break this many apps? What other options do we have?
>

Yes, expect it to be deployed in places where the access gear can only
do IPv4 and there is no money or technology available to bring in
IPv6.

Cameron

>
> Thanks,
> Serge
>

Re: iCloud - Is it going to hurt access providers?

[Cameron Byrne]

On Wed, Sep 7, 2011 at 9:28 AM, Joel jaeggli  wrote:
> On 9/7/11 09:02 , Michael Holstein wrote:
>>
>>> I would love a world where engineering was consulted by marketing :(
>>>
>>
>> Wouldn't be a problem is management invested based on engineering's
>> recommendations.
>>
>> There are few problems that money can't solve .. in this case, it's
>> "sure, we can offer unlimited bandwidth, we just need to build (x) new
>> towers at this map of locations, based on our usage patterns".
>
> The way to achieve a return on invested capital is to attract and retain
> customers who pay for a service which they find compelling.

Good simplification, but i think this thread is about the word "pay"
 who and how much.

RE: NAT444 or ?

[Cameron Byrne]

On Sep 8, 2011 1:47 AM, "Leigh Porter"  wrote:
>
>
>
> > -Original Message-
> > From: Owen DeLong [mailto:o...@delong.com]
> > Sent: 08 September 2011 01:22
> > To: Leigh Porter
> > Cc: Seth Mos; NANOG
> > Subject: Re: NAT444 or ?
> >
> > > Considering that offices, schools etc regularly have far more than 10
> > users per IP, I think this limit is a little low. I've happily had
> > around 300 per public IP address on a large WiFi network, granted these
> > are all different kinds of users, it is just something that operational
> > experience will have to demonstrate.
> > >
> > Yes, but, you are counting individual users whereas at the NAT444
> > level, what's really being counted is end-customer sites not individual
> > users, so the term
> > "users" is a bit misleading in the context. A given end-customer site
> > may be from 1 to 50 or more individual users.
>
> Indeed, my users are using LTE dongles mostly so I expect they will be
single users. At the moment on the WiMAX network I see around 35 sessions
from a WiMAX modem on average rising to about 50 at peak times. These are a
combination of individual users and "home modems".
>
> We had some older modems that had integrated NAT that was broken and
locked up the modem at 200 sessions. Then some old base station software
died at about 10K sessions. So we monitor these things now..
>
>
> >
> > > I would love to avoid NAT444, I do not see a viable way around it at
> > the moment. Unless the Department of Work and Pensions release their /8
> > that is ;-)
> > >
> >
> > The best mitigation really is to get IPv6 deployed as rapidly and
> > widely as possible. The more stuff can go native IPv6, the less depends
> > on fragile NAT444.
>
> Absolutely. Even things like google maps, if that can be dumped on v6,
it'll save a load of sessions from people. The sooner services such as
Microsoft Update turn on v6 the better as well. I would also like the CDNs
to be able to deliver content in v6 (even if the main page is v4) which
again will reduce the traffic that has to traverse any NAT.
>
> Soon, I think content providers (and providers of other services on the
'net) will roll v6 because of the performance increase as v6 will not have
to traverse all this NAT and be subject to session limits, timeouts and
such.
>

What do you mean by performance increase? If performance equals latency, v4
will win for a long while still. Cgn does not add measurable latency.

Cb
> --
> Leigh
>
>
> __
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> __
>

Re: NAT444 or ?

[Cameron Byrne]

On Sep 9, 2011 10:54 PM, "Dobbins, Roland"  wrote:
>
> On Sep 10, 2011, at 12:46 PM, Mark Tinka wrote:
>
> > GPRS/3G/EDGE has made many a mobile provider especially notorious.
>
> All this problematic state should be broken up into smaller instantiations
and distributed as close to the access edge (RAN, wireline, etc.) as
possible in order to a) reduce the amount of state concentrated in a single
device and b) to minimize the impact footprint when aberrant traffic
inevitably fills up the state tables and said devices choke.
>

Ip mobility via gtp or mobile ip generally does not work when you nat at the
'edge'.  If you don't want your ip address to change every time you change
cell sites, the nat has to be centralized.

Cb
> ---
> Roland Dobbins  // 
>
>The basis of optimism is sheer terror.
>
>  -- Oscar Wilde
>
>

Re: NAT444 or ?

[Cameron Byrne]

On Sep 11, 2011 4:33 AM, "Dobbins, Roland"  wrote:
>
> On Sep 11, 2011, at 4:02 PM, Leigh Porter wrote:
>
> > I'd agree that, usually, distributed is better but these are not
distributed networks, there is a single point (or a few large single points)
of contact.
>
> The point is that these aggregations of state are quite vulnerable, and
therefore they should be as distributed as is practicable.
>

I don't disagree with that principle, but other priciples around scale,
cost, and oam say that we get one big box called a cgn. And, that is the
reality of service provider nat in the real world today.

For mobile providers, the cgn generally follows the mobility anchor points.
For some national providers that means nfl cities, for others that means one
per timezone.

Cb

> ---
> Roland Dobbins  // 
>
>The basis of optimism is sheer terror.
>
>  -- Oscar Wilde
>
>

Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates

[Cameron Byrne]

On Sep 10, 2011 11:38 PM, "Damian Menscher"  wrote:
>
> On Fri, Sep 9, 2011 at 11:33 PM, Jimmy Hess  wrote:
>
> > On Fri, Sep 9, 2011 at 4:48 PM, Marcus Reid 
wrote:
> > > On Wed, Sep 07, 2011 at 09:17:10AM -0700, Network IP Dog wrote:
> > > I like this response; instant CA death penalty seems to put the
> > > incentives about where they need to be.
> >
> > I wouldn't necessarily count them dead just yet;  although their legit
> > customers must be very unhappy  waking up one day to find their
> > legitimate working SSL certs suddenly unusable
> >
> > So DigiNotar lost their "browser trusted"  root CA status.  That
> > doesn't necessarily mean they will
> > be unable to get other root CAs to cross-sign CA certificates they
> > will make in the future, for the right price.
> >
> > A cross-sign with CA:TRUE  is  just as good as being installed in
> > users' browser.
> >
>
> The problem here wasn't just that DigiNotar was compromised, but that they
> didn't have an audit trail and attempted a coverup which resulted in real
> harm to users.  It will be difficult to re-gain the trust they lost.
>
> Because of that lost trust, any cross-signed cert would likely be revoked
by
> the browsers.  It would also make the browser vendors question whether the
> signing CA is worthy of their trust.
>

Yep. The CA business is one of trust. If the CA is not trusted, they are out
of business.

Cb

> Damian
> --
> Damian Menscher :: Security Reliability Engineer :: Google

Re: wet-behind-the-ears whippersnapper seeking advice on building a nationwide network

[Cameron Byrne]

On Sep 17, 2011 10:41 AM, "Randy Bush"  wrote:
>
>  As an ISP, ARIN will not give you any space if you are new. You
>  have to already have an equivalent amount of space from another
>  provider.
> >>> does arin *really* still have that amazing barrier to market
> >>> entry?
> >> Yes.  If you want PI space, you have to start off with PA space,
> >> utilize it, and then apply for PI space and an AS #, with contracts
> >> demonstrating your intention to multihome.  Then, you have to
> >> *migrate* off the PA space and surrender it back to the 'owner'.  You
> >> cannot get further PI allocations until you've done this.
> > The ARIN community is easily it's own worst enemy.
>
> the arin policy weenie industry is one of the internet's worst enemies
>
> randy
>

+1

I will echo my displeasure with the idea that you can only get a lot if you
already have a lot.  This mess is enough to make cgn look appealing...

One more reason we can all do ourselves a favor by moving to ipv6, remove
the number scarcity issue and associated baggage of begging for numbers

Cb

Re: wet-behind-the-ears whippersnapper seeking advice on building a nationwide network

[Cameron Byrne]

On Sep 18, 2011 1:08 PM, "Benson Schliesser"  wrote:
>
>
> On Sep 18, 2011, at 15:51, Randy Bush  wrote:
>
> >> I'm told of others that have bought legacy IPv4 prefixes with no
> >> intention of updating whois at this time - no desire to enter into a
> >> relationship with ARIN and be subjected to existing "policy", for
> >> instance.
> >
> > so your point is that your friends at depository.com will be attractive
> > to ip address space buyers because they will offer a less religious rsa.
> > and the question is whether the ops community will believe their whois
> > and install a separate rpki trust root for them?
>
> For instance, yes.
>
> I'm also wondering if the ops community will accept other sources of proof
such as legal documents (or something else?), in lieu of Whois records from
an RIR, Depository, or elsewhere.
>
> > could be.  but i would not want to have that as my business plan.
> >
> > randy, who is all for a less religious rsa
>
> You wouldn't bet on ARIN being religious for the foreseeable future? ;)
Or, you wouldn't bet on the ops community embracing alternatives?
>
> Cheers,
> -Benson
>

Call me optimistic but  ipv6 does not have these issues...

For anyone making STRATEGIC choices about ipv4 investments... beware of
sharks in these waters, not just the cgn pains

Are we having fun yet?

Cb

Re: akamai rate limiting?

[Cameron Byrne]

On Sep 20, 2011 7:54 PM, "Joseph Gersch"  wrote:
>
> Does anyone know if Akamai edgesuite servers rate limits or blacklists
caching servers that query it too often?  It appears that queries are timing
out if we exceed a query load to edgesuite.
>
>  Does anyone at Akamai know if there are any changes to rate limiting or
an abnormally high load?
>
>

Akamai traffic is dropping on my network now.

Emailed their noc, no eta on fix

Cb
>
> Joseph Gersch
> Chief Operating Officer
> Secure64 Software Corporation
>
>
>

Re: akamai rate limiting?

[Cameron Byrne]

On Sep 21, 2011 4:43 PM, "Patrick W. Gilmore"  wrote:
>
> On Sep 20, 2011, at 11:17 PM, Cameron Byrne wrote:
> > On Sep 20, 2011 7:54 PM, "Joseph Gersch" 
wrote:
> >>
> >> Does anyone know if Akamai edgesuite servers rate limits or blacklists
> >> caching servers that query it too often?  It appears that queries are
timing
> >> out if we exceed a query load to edgesuite.
> >>
> >> Does anyone at Akamai know if there are any changes to rate limiting or
> >> an abnormally high load?
>
> > Akamai traffic is dropping on my network now.
> >
> > Emailed their noc, no eta on fix
>
> Cameron & I have been in contact off-list, and all issues have been
resolved.
>
> More generally: Hopefully it will come as no surprise that Akamai has some
rate-limiting parameters configured.  The Internet is a nasty place, and
every contentious provider should have protections in place.
>
> If anyone sees any problems with Akamai name servers or anything else,
n...@akamai.com is monitored 24/7 and should be able to either help directly,
or get you in touch with the right people who can.
>

Thanks to Patrick and team at Akamai for resolving this quickly

Cb

> --
> TTFN,
> patrick
>
>

Nxdomain redirect revenue

[Cameron Byrne]

Just an fyi for anyone who has a marketing person dreaming up a big nxdomain
redirect business cases, the stats are actually very very poor... it does
not make much money at all.

It is very important to ask the redirect partners about yields... meaning,
you may find that less than 5% of nxdomain redirects can be actually served
an ad page because 95%+ of nxd are printer lookups and such that cannot be
served an ad page.  Then from that less than 5% pool, the click through
rates are around 1%

Net net, no free money of any meaningful value.  But, ymmv... but I don't
think by much.

Cb

Re: Nxdomain redirect revenue

[Cameron Byrne]

On Sep 26, 2011 1:29 AM, "Florian Weimer"  wrote:
>
> * Cameron Byrne:
>
> > It is very important to ask the redirect partners about yields...
meaning,
> > you may find that less than 5% of nxdomain redirects can be actually
served
> > an ad page because 95%+ of nxd are printer lookups and such that cannot
be
> > served an ad page.  Then from that less than 5% pool, the click through
> > rates are around 1%
>
> Is this with strict NXDOMAIN rewriting, or were existing names
> redirected as well?  (AFAIK, most platforms do the latter, hijacking
> bfk.de, for example.)
>

I have no experience with hijacking real names, which others have noted is
evil.

Cb
> --
> Florian Weimer
> BFK edv-consulting GmbH   http://www.bfk.de/
> Kriegsstraße 100  tel: +49-721-96201-1
> D-76133 Karlsruhe fax: +49-721-96201-99

Re: Sprint 3G/4G PPTP VPN connectivity

[Cameron Byrne]

On Mon, Sep 26, 2011 at 10:30 AM, Seth Mattinen  wrote:
> On 9/26/11 8:36 AM, Drew Weaver wrote:
>> Has anyone been able to pull any magic off that allows PPTP connectivity 
>> over sprint's 3G/4G wireless network?
>>
>> I assume they're just filtering it flat out, but before I contact them I 
>> wanted to see if anyone has found a resolution on their own.
>>
>> I have several Nexus S 4G devices which are unable to get PPTP connections 
>> over 3G/4G but if you enable WIFI it comes up instantly.
>>
>> I've been researching this off and on all weekend but wondered if anyone 
>> else had run into this issue.
>>
>
>
> I use often use PPTP on my original HTC EVO. Just tested it now and it
> worked. 3G only, no 4G in my city.
>

I have seen MTU issues with PPTP on cellular networks before with
Android.  You might want to try clamping the MTU down on the server
side.

Cameron

Re: How Skype uses the network [was: News item: Blackberry services down worldwide]

[Cameron Byrne]

On Fri, Oct 14, 2011 at 12:11 PM, Patrick W. Gilmore  wrote:
> On Oct 13, 2011, at 7:26 PM, Matthew Kaufman wrote:
>> On 10/13/11 3:30 PM, Patrick W. Gilmore wrote:
>>> In fact, Skype, just as a for instance, is worse on hotel wifi as launching 
>>> the app on a laptop makes you a middle node for some conversations.
>>
>> Per the Skype IT administrator guide, a Skype node will not become a 
>> supernode unless it has a public IP address and meets the memory, bandwidth, 
>> and uptime requirements. It will not become a relay node unless it has a 
>> public IP address and is directly reachable from the Internet.
>>
>> It is very unlikely that launching the Skype app on a laptop on hotel wi-fi 
>> would meet these requirements.
>
> In the last 5 seconds, without touching Skype or having any active voice or 
> chat sessions open, my computer has had communication with 14 IP addresses.  
> Here is a sample of some:
>
>        TiggerAir-i7-2:~ patrick$ host 94.193.99.152
>        152.99.193.94.in-addr.arpa domain name pointer 
> 94-193-99-152.zone7.bethere.co.uk.
>        TiggerAir-i7-2:~ patrick$ host 78.90.137.244
>        Host 244.137.90.78.in-addr.arpa. not found: 3(NXDOMAIN)
>        TiggerAir-i7-2:~ patrick$ host 175.129.63.150
>        150.63.129.175.in-addr.arpa domain name pointer 
> KD175129063150.ppp-bb.dion.ne.jp.
>        TiggerAir-i7-2:~ patrick$ host 218.190.29.244
>        Host 244.29.190.218.in-addr.arpa. not found: 3(NXDOMAIN)
>        TiggerAir-i7-2:~ patrick$ host 128.2.238.215
>        215.238.2.128.in-addr.arpa domain name pointer 
> ETC-NALZAYER.ETC.CMU.EDU.
>        TiggerAir-i7-2:~ patrick$ host 212.187.172.66
>        Host 66.172.187.212.in-addr.arpa. not found: 3(NXDOMAIN)
>
> Those do not look like Skype servers.  I guess it is possible everyone in my 
> contact list is somehow pinging me, but that seems a little bit silly.
>
> My IP address is 172.30.19.19, hopefully I do not have to explain that this 
> is not a "public IP address".  I have been online a few minutes, so unless 
> their uptime requirements are about the same as a regular phone call, it is 
> too short.  I will admit, I have plenty of bandwidth available, though.
>

And, then there is the increasing prevalence of squat space which may
muddy common heuristics.

> In short, while they can claim my laptop is not being used as a supernode or 
> relay, Skype is still randomly talking to a slew of IP addresses.  Anyone 
> know what Skype is doing?
>
>
>>> Does Skype on $HANDHELD have the same property?
>> Not as far as I know, for the obvious reason that handheld devices have 
>> network connections that are suboptimal for this.
>
> The above happens to my laptop when I am on 3G / EDGE, even when I have a 
> 10-net address.  In fact, one of the first things I do on 3G is kill Skype 
> because it noticeably increases my network performance.
>
> I haven't checked on my iPhone 'cause I don't have things like tcpdump & 
> little snitch.
>
> --
> TTFN,
> patrick
>
>
>

Re: Manage an enterprise network? Please fill out my survey - for Science! :-)

[Cameron Byrne]

On Oct 31, 2011 9:13 PM, "Jack Bates"  wrote:
>
> On 10/31/2011 11:00 PM, Scott Whyte wrote:
>>
>> But seriously, if you can help her ascertain real middlebox use cases
she wants to help improve that segment of networking via useful research,
nothing more or less.
>
>
> Would love to see the results, although it definitely is catered more to
enterprise than ISP (where many of these are probably used more than in
enterprise).
>

Unfotunately ISPs are deploying many middle boxen, frequently in series,
for various reasons...cough cough cgn.

Given that these middle box infested ISPs are supposed to be providing
"internet", that seems like more fertile research grounds, as the
definition of internet is starting to shift ...at least imho.

Cb

> It's missing a small datapoint. What types of failures are most likely to
occur?(Physical/electrical, Misconfiguration, Overload)
>
> Layer-3 Routers -SOFTWARE BUGS!
>
> : )
>
> -Jack
>

IPv6 beta support for Android phones

[Cameron Byrne]

FYI.

T-Mobile USA now has opt-in beta support for an Android phone on IPv6,
more info here https://sites.google.com/site/tmoipv6/lg-mytouch

As far as i know, this is the first Android phone that support IPv6 on
the GSM/UMTS mobile interface.  Previous version of Android phones
supported IPv6 on WiFi and LTE.

Cameron

Re: IPv6 beta support for Android phones

[Cameron Byrne]

On Sun, Nov 6, 2011 at 8:32 AM, Tom Hill  wrote:
> On Fri, 2011-11-04 at 15:04 -0700, Cameron Byrne wrote:
>> FYI.
>>
>> T-Mobile USA now has opt-in beta support for an Android phone on IPv6,
>> more info here https://sites.google.com/site/tmoipv6/lg-mytouch
>
> Very, very good. I hope T-Mobile UK (and elsewhere in the world) take
> heed.
>
> I have to wonder why they've chosen to go with IPv6-only & DNS/NAT64
> instead of a dual-stack approach. Is there a particular restriction that
> prevents this?
>

There are a variety of reasons.  Most prominent is that if the issue
is lack of IPv4 addresses (public and private), dual-stack does not
solve this problem, each device still gets an IPv4 address.  Another
major issue is that in GSM/UMTS (3GPP pre-release 9), having
dual-stack means having 2 attachments to the network,  one for v4 and
one for v6.  Most mobile providers pay for most of their network kit
in terms of these attachments known as PDP.  Consequently, dual-stack
doubles the of the packet-core network.  If we take the licensing and
contractual parts out of the equations, double the attachments means
double the signalling and mobility events ... resulting in double the
CPU / Memory / blah ...

LTE does not have the dual attachment problem since there is the
concept of having v4 and v6 in one attachment, but it does not change
the fact that there are not enough IPv4 addresses to go around,
especially from a strategic planning perspective (let's design this
once for 5 to 10+ year life ...)


>> As far as i know, this is the first Android phone that support IPv6 on
>> the GSM/UMTS mobile interface.  Previous version of Android phones
>> supported IPv6 on WiFi and LTE.
>
> Indeed, the 'Network Info II' application will show you the IPv6
> addresses gained on WiFi interfaces (if anyone's interested). My Galaxy
> S (unlocked/orig.) does this very well.
>
> I wonder if it's possible to provide IPv6 support for UMTS/GSM via
> firmware and/or software updates from Samsung?
>

That's a good question for Samsung.  Most vendors would rather have
you buy a new device :(

CB

> Tom
>
>
>

Re: Cell-based OOB management devices

[Cameron Byrne]

On Nov 6, 2011 10:15 PM, "David Hubbard" 
wrote:
>
> Hi all, I am looking at cellular-based devices as a higher
> speed alternative to dial-up backup access methods for
> out of band management during emergencies.  I was
> wondering if anyone had experiences with such devices
> they could share?
>
> Devices I've found include Sierra Wireless AirLink Raven X,
> Digi's ConnectWAN 3G or 4G and Opengear's ACM5004-G.  I
> have no experience with any but they all appear to support
> the Sprint network which I assume would be ideal due to
> not having usage caps on data (currently).  The Opengear
> device runs linux and has four serial ports, a usb port
> for additional storage and ethernet, so it seems to have
> some small advantages over the others since it could double
> as an emergency self-contained management station you can
> SSH into and run diagnostics from.  All appear to have
> VPN/gateway support.
>
> What none of them are clear on is how you would connect
> to it over cellular since I assume you're just paying for
> a typical data plan and it will randomly obtain IP
> addresses.  Maybe some type of dynamic dns service so you
> can easily figure out your device's current IP?  How
> stable is the access to the device?  Any idea if any of
> them can do ipv6?
>

Another good question is if the 3g modem is firewalled by the mobile
provider so that incoming connections are blocked.

Cb
> Thanks!
>
> David
>
>

Re: Comcast IPv6 Update

[Cameron Byrne]

On Wed, Nov 9, 2011 at 8:40 AM, Jeroen Massar  wrote:
> On 2011-11-09 17:32 , Brzozowski, John wrote:
>> Update from http://www.comcast6.net
>> IPv6 Pilot Market Deployment Begins
>> Wednesday, November 9, 2011
>>
>> Comcast has started our first pilot market deployment of IPv6...
>
> Congrats! One step closer to full deployment!
>

+1

Glad to hear some good news about IPv6 deployment.  Now, lets talk
about deployment in Seattle :)

Re: Arguing against using public IP space

[Cameron Byrne]

On Sun, Nov 13, 2011 at 12:13 PM, William Herrin  wrote:
> On Sun, Nov 13, 2011 at 11:38 AM, Robert Bonomi
>  wrote:
>> On Sun, 13 Nov 2011 10:36:43 -0500, Jason Lewis  
>> wrote;
>>> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html
>>
>> Any article that claims a /12 is a 'class B', and a /16 is a 'Class C', is
>> DEFINITELY 'flawed'.
>
> Hi Robert,
>
> Give the chart a second look. 192.168.0.0/16 (one of the three RFC1918
> spaces) is, in fact, a /16 of IPv4 address space and it is, in fact,
> found in the old "class C" range. Ditto 172.16.0.0/12. If there's a
> nitpick, the author should have labeled the column something like
> "classful area" instead of "classful description."
>
>
> On Sun, Nov 13, 2011 at 10:36 AM, Jason Lewis  wrote:
>> I've always looked at private IP space as more of a
>> resource and management choice and not a security feature.
>
> Hi Jason,
>
> If your machine is addressed with a globally routable IP, a trivial
> failure of your security apparatus leaves your machine addressable
> from any other host in the entire world which wishes to send it
> packets. In the parlance, it tends to "fail open." Machines using
> RFC1918 or RFC4193 space often have the opposite property: a failure
> of the security apparatus is prone to leave them unable to interact
> with the rest of the world at all. They tend to "fail closed."
>

This "fail open" vs "fail closed" is a very good characterization of
the situation.  While many IPv4 situations requires RFC1918 addresses
due to scarcity, so it is a moot point, this fail open vs closed
argument applies very well to why one should consider IPv6 ULA
addresses in certain specific scenarios.  If the system does not need
to speak to the outside world, a ULA is frequently the right choice to
leverage this "fail closed" benefits, which IMHO outstrip any
advantages due to "not having to renumber when requirements change" or
whatever else the religiously anti-ULA folks have to say.

CB

> Think of this way: Your firewall is a deadbolt and RFC1918 is the lock
> on the doorknob. The knob lock doesn't stop anyone from entering an
> unlatched window, opening the door from the inside and walking out
> with all your stuff. Yet when you forget to throw the deadbolt, it
> does stop an intruder from simply turning the knob and wandering in.
>
> Regards,
> Bill Herrin
>
>
> --
> William D. Herrin  her...@dirtside.com  b...@herrin.us
> 3005 Crane Dr. .. Web: 
> Falls Church, VA 22042-3004
>
>

Re: Ok; let's have the "Does DNAT contribute to Security" argument one more time...

[Cameron Byrne]

On Nov 14, 2011 9:22 PM,  wrote:
>
> On Mon, 14 Nov 2011 19:06:13 EST, William Herrin said:
>
> > Using two firewalls in serial from two different vendors doubles the
> > complexity. Yet it almost always improves security: fat fingers on one
> > firewall rarely repeat the same way on the second and a rogue packet
> > must pass both.
>

Complexity equals downtime. I know at least one definition of security
includes availability .

> Fat fingers are actually not the biggest issue - a far bigger problem are
brain
> failures.  If you thought opening port 197 was a good idea, you will have
done
> it on both firewalls.  And it doesn't even help to run automated config
> checkers - because you'll have marked port 197 as "good" in there as
well. ;)
>
> And it doesn't even help with fat-finger issues anyhow, because you
*know* that
> if your firewall admin is any good, they'll just write a script that
loads both
> firewalls from a master config file - and then proceed to fat-finger said
> config file.

And, stateful firewalls are a very common dos vector.  Attacking firewall
sessions per second capacity and blowing up a session table can bring a
service down real quick. Furthermore, firewalls are frequently installed at
a choke point ... Which makes them a topological single point of
failure So, they are deployed in pairs  And therefore have a nice
cascading failure behavior when hit with a dos.

Cb

Re: Arguing against using public IP space

[Cameron Byrne]

On Nov 15, 2011 7:09 AM, "-Hammer-"  wrote:
>
> Guys,
>Everyone is complaining about whether a FW serves its purpose or not.
Take a step back. Security is about layers. Router ACLs to filter
whitenoise. FW ACLs to filter more. L7 (application) FWs to inspect HTTP
payload. Patch management at the OS and Application layer on the server.
Heuristics analyzing strategically placed SPAN feeds. The list goes on
depending upon the size of your enterprise.
>

I would say security is about stopping threats , not layering in technology
and tools. Granted, layer is a good idea, throwing everything including the
kitchen sink at a problem will result in just a larger problem.

> I don't think in a large environment you can avoid "complexity" these
days. What you have to succeed at is managing that complexity. And L3 FWs
have a very important purpose. They filter garbage. You focus your IDS/IPS
on what the FW is allowing. It's more than a screen door. But yes, it's
LESS than a true vault door. It's all about mitigating the risk. You'll
never be 100% full proof.
>

Large environments have to force simplicity to combat the natural ebb of
complexity.  The largest operators live by one rule , KISS.

L3 network fw are an attack vector and single point of failure.

But, I think this thread is not changing anyone's mind at this point.

> -Hammer-
>
> "I was a normal American nerd"
> -Jack Herer
>
>
>
>
> On 11/15/2011 08:56 AM, William Herrin wrote:
>>
>> On Tue, Nov 15, 2011 at 9:17 AM,  wrote:
>>
>>>
>>> And this is totally overlooking the fact that the vast majority of
*actual*
>>> attacks these days are web-based drive-bys and similar things that most
>>> firewalls are configured to pass through.
>>>
>>
>> Valdis,
>>
>> A firewall's job is to prevent the success of ACTIVE attack vectors
>> against your network. If your firewall successfully restricts
>> attackers to passive attack vectors (drive-by downloads) and social
>> engineering vectors then it has done everything reasonably expected of
>> it. Those other parts of the overall network security picture are
>> dealt with elsewhere in system security apparatus. So it's no mistake
>> than in a discussion of firewalls those two attack vectors do not
>> feature prominently.
>>
>> Regards,
>> Bill Herrin
>>
>>
>>
>>

Re: Big day for IPv6 - 1% native penetration

[Cameron Byrne]

On Mon, Nov 26, 2012 at 9:34 PM, Mark Andrews  wrote:
>
> In message , Mikael 
> Abrah
> amsson writes:
>> On Mon, 26 Nov 2012, Michael Thomas wrote:
>>
>> > I don't see either Apple or Microsoft as being the hindrance. In fact,
>> > both of them seem pretty ready, fsvo "ready". Unlike ISP's by and large.
>> > But I'm pretty sure that both iPhones and Androids are pretty happy
>> > about being in v6 land since I see them showing up in my logs all the
>> > time, for the few providers that have lit up v6.
>>
>> Not on the mobile side. Wifi yes, mobile no.
>>
>> > I'm all for bagging on those two, but it seems pretty unjustified here.
>>
>> What they need to start doing is testing Apps for IPv6 only access
>> capabilitity. This doesn't work today, Apps like Waze, Spotify and others
>> do not work on IPv6 only access.
>
> One could just start adding negative reviews to any product that
> doesn't work in a IPv6 only network.
>

Yes, you can start your reviews on Android with Skype, Netflix, and
Spotify all fail to work in an IPv6-only NAT64/DNS64 3G/4G network

This list needs to be updated, but it is a fair starting point
https://docs.google.com/spreadsheet/ccc?key=0AnVbRg3DotzFdGVwZWlWeG5wXzVMcG5qczZEZloxWGc#gid=0

It is also worth noting that folks can certainly test IPv6-only apps
using T-Mobile in the USA
https://sites.google.com/site/tmoipv6/lg-mytouch, that's just one data
point.

And, 464XLAT on Android does enable these broken application to work
correctly on an IPv6-only NAT64/DNS64 network
http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-08

464XLAT and IPv6 tethering code for Android here
http://dan.drown.org/android/clat/

CB

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

Re: Big day for IPv6 - 1% native penetration

[Cameron Byrne]

On Tue, Nov 27, 2012 at 11:28 AM, mike  wrote:
> On 11/26/12 8:59 PM, Mikael Abrahamsson wrote:
>>
>> On Mon, 26 Nov 2012, Michael Thomas wrote:
>>
>>> I don't see either Apple or Microsoft as being the hindrance. In fact,
>>> both of them seem pretty ready, fsvo "ready". Unlike ISP's by and large. But
>>> I'm pretty sure that both iPhones and Androids are pretty happy about being
>>> in v6 land since I see them showing up in my logs all the time, for the few
>>> providers that have lit up v6.
>>
>>
>> Not on the mobile side. Wifi yes, mobile no.
>
>
> You're saying there are no cellular v6 deployments? I'm about 99% certain
> that
> you're wrong. I see v6 addresses in my apache logs all the time and they're
> almost
> definitely while they're not on wifi (my site uploads gps data while people
> are skiing,
> so they're usually on cellular).
>
>>
>>> I'm all for bagging on those two, but it seems pretty unjustified here.
>>
>>
>> What they need to start doing is testing Apps for IPv6 only access
>> capabilitity. This doesn't work today, Apps like Waze, Spotify and others do
>> not work on IPv6 only access.
>
>
> Is this the app's fault? What are they doing wrong?
>


Yes, it is the app's fault.

They are either doing IPv4 literals or IPv4-only sockets

The IPv4 literal issues is when they do "wget http://192.168.1.1"; ...
hard coding IPv4 addresses... instead of using an FQDN like "wget
http://example.com";.  Using an FQDN allows the DNS64 to work
correctly.

The IPv4 literals fail since the IPv6-only host do not have an ipv4
address to bind to or an ipv4 route to follow.  This is the issue that
i believe Skype has ... since they use IPv4 addresses as part of their
signalling.  Another one is the URL re-director http://cs.co at Cisco.
 For example http://cs.co/6017pZhN  will bounce you via an IPv4
address literal  which means an IPv6-only user gets a webpage that
tries to load an IPv4 address and fails.

The other issue is that the developers choose to use IPv4-only socket
APIs instead of a generic network socket APIs that would allow v4 or
v6.  This is usually an education issue.  This is what i think is
wrong with the Netflix Android app, they tried to do some low level
network tweaks using the Android NDK but in doing these tweaks they
only used IPv4 socket APIs and fail to work on IPv6 natively or via
NAT64/DNS64.

CB

> Mike
>

Re: Big day for IPv6 - 1% native penetration

[Cameron Byrne]

On Tue, Nov 27, 2012 at 12:30 PM, Michael Thomas  wrote:
> On 11/27/2012 11:58 AM, Cameron Byrne wrote:
>>
>> On Tue, Nov 27, 2012 at 11:28 AM, mike  wrote:
>>>
>>>
>>>
>>> Is this the app's fault? What are they doing wrong?
>>>
>>
>> Yes, it is the app's fault.
>>
>> They are either doing IPv4 literals or IPv4-only sockets
>>
>> The IPv4 literal issues is when they do "wget http://192.168.1.1"; ...
>> hard coding IPv4 addresses... instead of using an FQDN like "wget
>> http://example.com";.  Using an FQDN allows the DNS64 to work
>> correctly.
>
>
> I can understand spotify, but don't really understand why waze

Why can you understand Spotify not working on IPv6?  Are they known
for having a generally shoddy product?

Pandora works fine on my IPv6-only NAT64/DNS64 setup.  As does Youtube
and many other multimedia services.

Is Waze much different from Google Maps?  Google Maps works great, as
does Mapquest on ipv6-only

And this is the conversation folks will have...: "Oh... Waze does not
work, you should try their competitor it works great"  and " I used to
use Spotify, then i changed networks and it stopped working... now i
use Pandora or Google Music"

> would have a problem unless they're doing some sort of rendezvous
> like protocol that embeds ip addresses. That said, I'd say that the
> vast majority of apps don't have this sort of problem and will quite
> unknowingly and correctly work with v6.
>

Yes, 85% of the Android apps i have tested (sample of over 200) work
fine on IPv6-only ... likely due to just good coding practices ... not
due to specific IPv6 engineering.

CB
> Mike

Re: Big day for IPv6 - 1% native penetration

[Cameron Byrne]

Sent from ipv6-only Android
On Nov 27, 2012 8:39 PM, "Mikael Abrahamsson"  wrote:
>
> On Tue, 27 Nov 2012, mike wrote:
>
>> You're saying there are no cellular v6 deployments? I'm about 99%
certain that you're wrong. I see v6 addresses in my apache logs all the
time and they're almost definitely while they're not on wifi (my site
uploads gps data while people are skiing, so they're usually on cellular).
>
>
> I am in Europe. None of Apple och Microsoft mobile devices will do IPv6
on the mobile side. I don't know if they do special versions for the US
market, but for general 3GPP networks, it doesn't work.
>

Verizon in the USA does have iOS on ipv6. Afaik, the network must ask for
it the same way all Android Samsung devices on t-mobile now have ipv6 as a
user option because it is part of the requirements for the oems.

Win phone 8 has a menu option for ipv6 but I don't think it works 

>
>> Is this the app's fault? What are they doing wrong?
>
>
> They try to detect if there is Internet connectivity and check only IPv4,
they use IPv4 literals and other things. I am not an app developer, I do
networking, and when I connect IPv6 only to Android or Windows, a lot of
things stop working. I haven't tried iPhone but I would believe the
situation is similar there.
>

Just to quantify,  a lot of things stop working = about 15% of the top 200
apps ... names like Skype, Spotify, tango and Netflix fail. Sorry to nit
pick, but I want to make sure the scope of the issue is well understood.

Meanwhile, 85% of the apps work fine like email (smtp, pop, imap,
exchange), gmail, chrome/firefox/opera, facebook, twitter, youtube, words
with friends, Google maps, mapquest ...

I have been v6-only on mobile for 2 years now, and I feel fine. I am
sending this email using a v6-only note2... dogfooding it. Yet, the rotten
apples spoil the bunch as the saying goes... and hence 464xlat.

CB

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

Re: Big day for IPv6 - 1% native penetration

[Cameron Byrne]

Sent from ipv6-only Android
On Nov 27, 2012 10:57 PM, "Mikael Abrahamsson"  wrote:
>
> On Tue, 27 Nov 2012, Cameron Byrne wrote:
>
>> Verizon in the USA does have iOS on ipv6. Afaik, the network must ask for
>> it the same way all Android Samsung devices on t-mobile now have ipv6 as
a
>> user option because it is part of the requirements for the oems.
>
>
> I have been trying to locate someone within Apple for months now to speak
about IPv6 on their mobile devices. The wall of silence is impressive.
>
> The android manufacturers at last respond, even though it's not always
the answer I want :P
>
>
>> Win phone 8 has a menu option for ipv6 but I don't think it works 
>
>
> Yeah, it's like the Galaxy Nexus which has IPv4v6 in the menu but if you
use it it asks for an IPv4 PDP context and when it gets it, it falls over
and needs to be rebooted.
>
>
>> I have been v6-only on mobile for 2 years now, and I feel fine. I am
sending this email using a v6-only note2... dogfooding it. Yet, the rotten
apples spoil the bunch as the saying goes... and hence 464xlat.
>
>
> Any progress with this, to get this into mainline?
>

Yes, there has been progress. These code parts have been merged into
mainline Android code base. Time to start bugging the oems, since it is
merged at the aosp level. There are still a peice pending review,  but
there is enough merged code to get the ball rolling for sure

https://android-review.googlesource.com/#/q/owner:dan-android%2540drown.org+status:merged,n,z

> Then again, I feel we'll have proper IPv4v6 PDP context before there is
any worthwile 464XLAT deployment, but for the long tail I would like to
have 464XLAT in all devices.
>
>

Maybe. But the goal is to get rid of ipv4 constraints on the ue, not simply
a foot race. But if 464xlat wins that race too, great.

CB

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

Re: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications"....

[Cameron Byrne]

Got some bad data here.  Let me help.

Sent from ipv6-only Android
On Nov 29, 2012 8:22 AM, "Michael Thomas"  wrote:

> Phone apps, by and large, are designed by people in homes or
> small companies. They do not have v6 connectivity. Full stop.
> They don't care about v6. Full stop. It's not their fault, even if
> you think they should invest a significant amount of time to fix
> theoretical problems.
>

Phone apps generally work with ipv6 since  they are developed using high
level and modern sdk's.

My sample says over 85% of Android Market top apps work fine on ipv6. For
folks to really get in trouble they need to be using NDK... that is where
the ipv4-only apis live, not SDK afaik ... NDK implies greater knowledge
and risk in Android.

The apps that fail are not from noobies in a garage. The failures are  from
Microsoft/Skype , Netflix , Amazon Prime streaming , Spotify and other well
heeled folks that are expected to champion technology evolution. And,
Microsoft and Netflix were certainly part of world v6 launch. They just
have more work to do.

I have more work to do.

Vzw and T-mobile USA both have ipv6.

So, please note: most Android apps work on v6. Millions of mobile phone
subscribers have ipv6 (all vzw LTE by default, all t-mobile samsung by
phone configuration). The problem apps are from top tech companies,  not
garage devs.

CB

Re: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications"....

[Cameron Byrne]

> "Everything you need to know" except for how to actually accomplish this
> task in the real world.
>
> In order to accomplish this in the real world using present-day software
> development methodologies you would need to do a few more things:
> - Generate some user stories that explain why the IPv6-supporting code needs
> to be written
> - Break these user stories down into backlog items and convince the product
> manager to place these items into the backlogs of the dozens or more
> interacting teams that need to write the code
> - Add all of the backlog items for all of the interworking pieces so that,
> for instance, automated monitoring tools that are watching the IPv4 services
> will now be watching the IPv6 services as well... capacity planning will be
> able to account for IPv6 growth... etc.
> - Convince the product manager (along with other departments like marketing
> and executive management) that adding support for IPv6 to an existing
> working product is *more important* than meeting internal and external
> requests for features and fixing known bugs
> - Develop a test plan so that the various interworking parts of your system
> may be tested internally once IPv6 support is added to ensure that not only
> does IPv6 now work but that the existing IPv4 functionality is not broken as
> a result
> - Write the code when the work makes its way to the top of the backlog
> - Wait for the infrastructure environment to be upgraded to support running
> IPv6 in production
> - Test the new IPv6 functionality and verify that none of the IPv4
> functionality is broken
> - Deploy to customers
> - Receive bug reports
> - Prioritize bugs that have been created that affect IPv4 customers and IPv6
> customers appropriately such that the IPv6 bugs ever get fixed
> - Iterate
>
> I'm sure I've missed a few steps.
>

There is another case where the customer does not ask for it.  I don't
think Google or Facebook's or Bing's customers meaningfully asked for
v6, yet they did it.  Same thing with Verizon LTE. Maybe the Bing
folks can help you with internal strategies for getting support.

>
>



>
> Matthew Kaufman
>
> ps. I work for a division of my employer that does not yet have IPv6 support
> in its rather popular consumer software product. Demand for IPv6 from our
> rather large customer base is, at present, essentially nonexistent, and

Nonexistent demand?  Let's bing it and decide
http://www.bing.com/search?q=skype+ipv6

Interesting hits my query are

http://community.skype.com/t5/Android/Skype-not-working-on-T-Mobile-USA-IPv6-with-UMTS-unlocked-Galaxy/td-p/380685

http://www.zdnet.com/voip-and-instant-messaging-problem-looming-skype-doesnt-support-ipv6-707058/

http://www.gossamer-threads.com/lists/nsp/ipv6/4

http://www.change.org/petitions/skype-add-ipv6-support-to-skype


http://www.gossamer-threads.com/lists/nsp/ipv6/41499

But, this is just the same old carping.  Skype / Microsoft should add
IPv6 support because it is the right thing to do for the Internet.
Microsoft, like Google and Facebook, was part of world v6 launch and
knows ipv6 is about making the internet better and bigger.

The Skype issue is so serious, that it is specifically blocking
IPv6-only architectures since it is THE most major app that breaks in
IPv6-only.  Skype is the killer app for 464XLAT ... which means that
since Skype refuses to evolve their product, the OS now has to have
hacks to fix it.

CB

> other things would be way above it in the stack-ranked backlog(s) anyway.
> One could argue that until we add IPv6 support throughout our systems,
> consumers will continue to demand IPv4 connectivity from operators in order
> to run software like ours, rather than us being cut off from any meaningful
> proportion of customers.
>
> pps. And until we were last acquired, we *didn't* have IPv6 at our
> developer's desktops. Now we do, but it doesn't connect to the global IPv6
> Internet (yet).
>

Re: looking glass for Level 3

[Cameron Daniel]

I've had issues getting to it for a week or so. Their NOC was 
unresponsive when queried.


On 2012-12-28 8:23 pm, Peter Ehiwe wrote:
I normally use the 3rd one you mentioned but they seem to be down at 
the

moment.

Rgds Peter,
Sent from my Asus  Transformer Pad
On Dec 28, 2012 1:51 AM, "Tassos Chatzithomaoglou" 


wrote:


Anyone have any looking glass for Level 3?

The following seem not to be working

http://www.level3.com/LookingGlass/
http://lg.level3.net/bgp/bgp.cgi
http://lookingglass.level3.net/

--
Tassos

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[Cameron Byrne]

Constantine,

On Fri, Jan 18, 2013 at 6:56 PM, Constantine A. Murenin
 wrote:
> On 16 January 2013 08:12, fredrik danerklint  wrote:
>> From the article:
>>
>> "Faced with the shortage of IPv4 addresses and the failure of IPv6 to take
>> off, British ISP PlusNet is testing carrier-grade network address
>> translation CG-NAT, where potentially all the ISP's customers could be
>> sharing one IP address, through a gateway. The move is controversial as it
>> could make some Internet services fail, but PlusNet says it is inevitable,
>> and only a test at this stage."
>>
>> http://tech.slashdot.org/story/13/01/16/1417244/uk-isp-plusnet-testing-carrier-grade-nat-instead-of-ipv6
>>
>> I'm only here to bring you the news. So don't complain to me...
>
> It is obvious that implementing CGN requires a lot of extra resources
> and a lot of hardware/firmware support for both CPE and operator
> equipment (the latter from both technical and legal-compliance
> reasons, and both the former and the latter in order to implement some
> kind of UPnP-compatible support to still allow some kind of p2p apps
> to somehow function).
>
> And this is at a time when a lot of the world internet traffic has
> already moved to IPv6, and all major content providers that account
> for most of the traffic today already support native IPv6: Google,
> YouTube and FB.
>
> Wouldn't it be better instead of the untested, unscalable and dead-end
> IPv4 CGN to massively start implementing single-stacked IPv6 with
> NAT64 at the ISP and *464XLAT* within the CPE RG?  (With 464XLAT, you
> wouldn't even need a potentially troublesome DNS64.)  This way,
> instead of having to account for subscriber growth presenting
> scalability issues on your limited IPv4 resources and CGN-related
> concerns, you can instead account for the content growth of
> IPv6-enabled sites, and, basically, have to plan for just about no
> extra IPv4 scaling budget whatsoever, since with every X subscribers
> that still need IPv4, you'll have every XX old subscribers that will
> be moving closer to being IPv6-only.  And with every year, a single
> IPv4 address used for NAT64 will be perfectly able to scale up to
> serve more and more customers, since fewer and fewer people will need
> IPv4 connections.
>
>
> So:
>
> With CGN, we get to the same old chicken-and-egg story:  lack of IPv6
> deployment and content/app support, yet an even more imminent shortage
> of IPv4 addresses (and with every new customer you'll be so much more
> closer to it) and the scalability and legal issues.
>
> With 464XLAT on the CPE RG and NAT64 at the carrier instead, you get
> all the benefits of CGN (namely, all non-p2p IPv4-only apps and
> services will still work perfectly fine), but only a couple of the
> drawbacks.  And it'll actually put the correct pressure for both
> content and application developers to immediately switch to IPv6, and
> avoid you, the operator, from having to be spending the extra
> resources and having extra headaches on the IPv4 address shortage.  It
> really makes no sense that any company would still want to invest a
> single dime into CGN when instead they could be investing in IPv6 with
> NAT64 and CPE RGs with 464XLAT.
>

Brilliant so far ...

> I honestly think that 464XLAT can potentially solve all the chicken
> and egg problems that the big players have been having.  Supposedly,
> that's how T-Mobile USA is planning to move their network forward.
> (I'm certainly looking towards the day when I could finally enable
> IPv6 on a Google Nexus on T-Mo.)
>

OK... i am wading into dangerous territory now:  Why are you waiting?

This page has the 464XLAT software and procedure for Nexus S, Galaxy
Nexus, as well as apk for any rooted Android that can handle IPv6 on
cellular http://dan.drown.org/android/clat/

Or for the more pure IPv6-only NAT64/DNS64 out-of-the-box experience
https://sites.google.com/site/tmoipv6/lg-mytouch

> On the other hand, it's really strange that 464XLAT is so brand bloody
> new when IPv6 itself, as well as even NAT64 and DNS64, have been there
> for ages.  The idea of 464XLAT is just so ingeniously straight and
> simple!  Somewhat similar to 6rd, I guess.
>

Well, i certainly fought it as long as i could.  I was really drinking
the Kool-Aid that apps that could not support IPv6 would be
de-selected since they were unfit for the internet.  I figured
evolution would win, but inertia was certainly making things too slow,
thus we needed a way to make IPv4-apps (cough cough Skype, Netflix
Android App, ...) work on IPv6.

> I think that instead of any kind of CGN, all residential (and mobile)
> broadband connections should be IPv6-only with NAT64 and 464XLAT.
> That'll basically solve all the actual problems with one stone: lack
> of IPv6 deployment from content publishers and IPv6 application
> support (from app developers with no IPv6), and the immediate shortage
> of the IPv4 addresses.
>
> Cheers,
> Constantine.
>

Rock on.  I have been on IPv6-only + NA

Re: Network security on multiple levels (was Re: NYT covers China cyberthreat)

[Cameron Byrne]

On Wed, Feb 20, 2013 at 9:13 AM, Jay Ashworth  wrote:
> - Original Message -
>> From: "Warren Bailey" 
>
>> We as Americans have plenty of things we have done halfass.. I hope an
>> Internet kill switch doesn't end up being one of them. Build your own
>> private networks, you can't get rooted if someone can't knock. Simple
>> as that.
>
> Well, Warren, I once had a discussion with someone about whether dedicated
> DS-1 to tie your SCADA network together were "secure enough" and they asked
> me:
>
> "Does it run through a DACS? Where can you program the DACS from?"
>

Did you open that PDF regarding DACS security ?

 http://money.cnn.com/2013/02/20/news/economy/hacking-infrastructure/index.html

CB


> Cheers,
> -- jra
> --
> Jay R. Ashworth  Baylink   
> j...@baylink.com
> Designer The Things I Think   RFC 2100
> Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
> St Petersburg FL USA   #natog  +1 727 647 1274
>

Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?

[Cameron Byrne]

Hi,

In-line

On Tue, Mar 5, 2013 at 9:55 AM, Mukom Akong T.  wrote:
> Dear experts,
>
> I've found myself thinking about what ground an engineer needs to cover in
> order to convince the executives to approve and commit to an IPv6
> Deployment project.
>
> I think such a presentation (15 slides max in 45 minutes) should cover the
> following aspects:
>
> a) Set the strategic context: how your organisation derives value from IP
> networks and the Internet.
>
> b) Overview of the problem: IPv4 exhaustion
>
> c) Implications of IPv4 Exhaustion to your organization’s business model.
>
> d) Introduction of IPv6 as a solution to IPv4 exhaustion.
>
> e) Understanding the risks involved.
>
> f) How much will deploying IPv6 will cost.
>
> g) Call to action.
>
> I've detailed my thinking into each of these items at  to Executive Management – Guidance for
> Engineers
>>
>
> My question and this is where I'd appreciate some input:
>
> a) To all you engineers out there who have convinced managers - what else
> did you have to address?
>

One of the most important things i see not being stressed enough is
that IPv6 is frequently free or a low-cost incremental upgrade.

So, when calculating ROI / NPV, the hurdle can be very low such that
the cash in-flow / cost savings is not a huge factor since the
required investment is close to nil.

This is not always the case, some legacy stuff won't work on ipv6
without investment.  But, as a plug to all you folks who work at
companies that use a CDN, please ask your CDN to turn IPv6 on for your
website.  This is top-of-mind for me since i just pushed my www folks
on this issue


Here's some relevant pointers for the CDN folks, in many cases its
just a matter of clicking a button in the management portal:

Akamai http://www.akamai.com/ipv6

Edgecast http://www.edgecast.com/ipv6/

Cloudflare https://www.cloudflare.com/ipv6

Amazon 
http://aws.amazon.com/about-aws/whats-new/2011/05/24/elb-ipv6-zoneapex-securitygroups/

Softlayer http://www.softlayer.com/about/network/ipv6


> b) To you who are managers, what else do you need your engineers to address
> in order for you to be convinced?
>
> Regards.
>
> As always, all opinions expressed are mine and do not necessarily represent
> the views of my employers, past or present.
>
> --
>
> Mukom Akong T.
>
> http://about.me/perfexcellence |  twitter: @perfexcellent
> --
> “When you work, you are the FLUTE through whose lungs the whispering of the
> hours turns to MUSIC" - Kahlil Gibran
> ---
> --
>
> Mukom Akong T.
>
> http://about.me/perfexcellence |  twitter: @perfexcellent
> --
> “When you work, you are the FLUTE through whose lungs the whispering of the
> hours turns to MUSIC" - Kahlil Gibran
> ---

Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?

[Cameron Byrne]

On Tue, Mar 5, 2013 at 6:46 PM, Mukom Akong T.  wrote:
> On Wed, Mar 6, 2013 at 12:34 AM, Mike.  wrote:
>
>> I would lean towards
>>
>>   f) Cost/benefit of deploying IPv6.
>>
>
> I certainly agree, which is why I propose understanding you organisation's
> business model and how specifically v4 exhaustion will threaten that. IPv6
> is the cast as a solution to that, plus future unknown benefits that may
> result from e-2-e and NAT elimination.
>
> I have no clue how to sell 'benefit' of IPv6 in isolation as right now even
> for engineers, there's not much of a benefit except more address space.
>
>

That is really the meat of it, more addresses is the killer IPv6 app.
If you have plenty of ipv4, your situation is not very urgent, but one
day it will be urgent There are folks who don't have much IPv4,
and sometimes people on your network may want to communicate with
them.. Like the folks in Europe or Asia.  Remember, APNIC and RIPE are
both out of IPv4 right now.   So all meaningful growth (mobile, cloud,
internet of things...) must happen on IPv6 ... or relatively expensive
IPv4 addresses from the black market and / or NATs

CB

> --
>
> Mukom Akong T.
>
> http://about.me/perfexcellence |  twitter: @perfexcellent
> --
> “When you work, you are the FLUTE through whose lungs the whispering of the
> hours turns to MUSIC" - Kahlil Gibran
> ---