Re: Creating demand for IPv6

[William Herrin]

On 10/3/07, Mark Smith
<[EMAIL PROTECTED]> wrote:
> The value of network perimeterisation as a security measure, of which
> NAT is a method, is being questioned significantly by network security
> people.

Mark,

The discussion at hand is whether the absence of NAT creates a drag on
IPv6 deployment. and how much of a drag it creates. Your points about
the relative merits of NAT as a security mechanism are entirely
irrelevant to that discussion.


On 10/3/07, Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote:
> On 3-okt-2007, at 5:20, William Herrin wrote:
> > 1. End the insanity of having software prefer IPv6 if available (
> > records over A records).
>
> Insanity?

Yes, Iljitsch, insanity.

Trying IPv6 first is asking folks to disable it on their PCs the
second or third time they can't get to a web site because the IPv6
path isn't working. Its also asking web site operators not to offer
IPv6 addresses in the first place so as not to inconvenience folks who
have Ipv6 turned on without a reliable connection.

That's counterproductive. We want people on both sides to turn it on
and leave it on.

We don't need every PC in the world to be a beta tester for our new
Internet. We do need them to turn it on.

Regards,
Bill


-- 
William D. Herrin  [EMAIL PROTECTED]  [EMAIL PROTECTED]
3005 Crane Dr.Web: 
Falls Church, VA 22042-3004

Re: Creating demand for IPv6

[William Herrin]

On 10/3/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > However, if there was a reasonable translation mechanism
> > available which allowed IPv6-only end systems to access
> > IPv4-only content, I think the picture would look quite
> > different.
>
> Doesn't deploying a 6to4 relay in the content provider network, along
> with IPv6 access to the content provider network, exactly meet this
> requirement?

Michael,

Not in any way, shape or form, no.

6to4 allows folks whose upstream provider is IPv4 only to connect
their IPv6 hosts to other IPv6 hosts via IPv6. It does exactly that
and nothing else.

If you run a web site and only have IPv6 access via 6to4, you SHOULD
NOT publish a  record. 6to4 has very few gateways and they get
clogged at various times of the day. If you publish a  record,
every user who has IPv6 will first try to connect to you via IPv6 and
experience a -long- delay.


> > Perhaps the assignment of IPv4 addresses to end users could
> > become a premium service available to those who need them,
> > leaving cheaper, IPv6-only service for everybody else.
>
> I'm quite sure that this WILL happen within a year or so. Lots of ISPs
> have already gotten their IPv6 through the trial phase and already offer
> IPv6 access service, or are about to offer it.

If you care to wager, I'll take some of that action. Without a
relatively transparent mechanism for IPv6-only hosts to access
IPv4-only sites this isn't going to happen. We don't have such a
mechanism built and won't have it deployed in 12 months.

Regards,
Bill Herrin

-- 
William D. Herrin  [EMAIL PROTECTED]  [EMAIL PROTECTED]
3005 Crane Dr.Web: 
Falls Church, VA 22042-3004

Re: Creating demand for IPv6

[Joe Greco]

> > It isn't that simple.  The fact that NAT exists and is seen as useful  
> > by many people (whether or not they are even aware of it) means  
> > services and applications need to be aware of it.
> 
> This is a hidden cost of NAT. Why hack many applications to work around
> a network layer problem ?
> 
> The best place to fix a problem is where it actually exists. The
> problem NAT tries to solve, but doesn't solve very well (see the
> earlier list), exists in the network layer. IPv6 fixes the network
> layer problem that IPv4 has, and it fixes it better than NAT does. IPv6
> isn't perfect, but nothing ever is. 

I think that you've misidentified where the problem really exists.

I'd suggest that it exists at a higher layer.  If I'm a resi broadband 
subscriber, and I buy an "Internet connection thingamajigger", I may want
to hook up more than the one device I'm allowed, in a hypothetical IPv4-
only world that works like the one we currently have.  And yes, while SOME 
ISP's do allow you to obtain additional IP addresses, it is certainly not
common, nor is it without a monthly cost.  Smart end users WILL identify 
that things like "Internet Connection Sharing" or a NAT gateway will 
eliminate this cost.

So, one of the real problems is that ISP's sell connections "for a single
device" to end users.  Another problem could be that these are dynamic IP,
which makes ever less sense given the nature of always-on Internet access,
and the increasing plethora of Internet-capable devices one finds in a
home.

I realize that these things have typically been differentiators in the
service offerings of an ISP, but if you really want to be able to get rid
of NAT and truly "go IPv6 native", you're going to have to get rid of the
incentives to put a NAT device in, and give end users blocks of address
space sufficient to the task.

Most proponents of IPv6 seem to be operating under the assumption that
an ISP will hand out a block (the latest I recall seeing is RFC 4779,
which suggests a /64, IIRC).  That would appear to be sufficient to the
task, certainly.

However, I am left wondering what is going to happen in the event that
you're dealing with a service provider who really wants to spec out that
a single client is allowed to attach?  Because there's a loose correlation
between the number of clients behind a connection and actual utilization,
carriers have an incentive to limit this...

To really encourage the avoidance of NAT, we really need to move to
service models where Internet connection sharing is expected and allowed.
Limited to within a household?  Not technically possible, of course, but
you can certainly /write/ such a restriction into the contract.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)

[Daniel Senie]

At 04:07 PM 10/2/2007, Iljitsch van Beijnum wrote:



On 2-okt-2007, at 16:53, Mark Newton wrote:


By focussing on the mechanics of inbound NAT traversal, you're
ignoring the fact that applications work regardless.  Web, VoIP,
P2P utilities, games, IM, Google Earth, you name it, it works.


O really? When was the last time you successfully transferred a file
using IM? It only works half the time for me and I don't even use NAT
on my main system myself. Some audio/video chat applications work
well, others decidedly less so. The only reason most stuff works most
of the time is because applications tell NAT devices to open up
incoming ports using uPnP or NAT-PMP.


By policy, I generally block file transfer over IM at security 
boundaries where possible, whether NAT is in use. End users on 
corporate networks do not need to be using IM as a file transfer mechanism.




IPv6 will happen.  Eventually.  And it'll have deficiencies which
some believe are "severe", just like the IPv4 Internet.  Such as
NAT.  Deal with it.


If you want NAT, please come up with a standards document that
describes how it works and how applications can work around it.


Been there, and done that. Please go read RFC 3235, and read the 
other RFCs that came out of the NAT Working Group in the IETF. This 
WG documented how things worked, and how to write apps and such. NAT 
itself had been in widespread use for a long time before, though 
implementations varied in both function and terminology. Having a 
common point of reference, and recommendations for living with it 
seemed to many like a good idea. It appears the documents have not 
been widely read.



 Just
implementing it and letting the broken applications fall where they
may is so 1990s.


If you believe that v4 exhaustion is a pressing problem, then I'd
humbly suggest that 2007 is a good time to shut the hell up about
how bad NAT is and get on with fixing the most pressing problem.


"NAT is not a problem" and "running out of IPv4 address space is a
problem" can't both be true at the same time. With enough NAT
lubrication you can basically extend the IPv4 address space by 16
bits so you don't need IPv6.


Running out of address space may well have been a problem a decade 
ago without NAT. You and I don't know, largely because none of us 
really knows how many computers are behind NAT boxes today. But the 
IETF was not ready to provide a replacement for IPv4 at the time. So 
NAT bought the IP protocol stack enough time to dominate the marketplace.




If we're successful, there'll be plenty of time to go back and
re-evaluate NAT afterwards when IPv6 exhaustion is a distant memory.


Right. Building something that can't meet reasonable requirements
first and then getting rid of the holes worked so well for the email
spam problem.


This is a rather disingenuous argument. You might look at the history 
of TCP, which has had several tweaks over the years as more was 
learned. In trying to have every duck perfectly in a row, IPv6 is 
quite late to the party. Even NASA launches deep space probes before 
operational software is finished, and updates it in flight... (OK, so 
maybe that's a bad example, given math errors and a certain crash on mars).

Re: Creating demand for IPv6

[Elmar K. Bins]

[EMAIL PROTECTED] (Joe Abley) wrote:

> 6to4 (for content- or access-focussed networks) is surely a solution  
> to the problem of "I have no good way to acquire IPv6 transit";

It solves another problem as well, like "I cannot go v6 to
my servers because my load balancing and packet filtering
black boxes don't do it yet".

Elmar.

Re: Creating demand for IPv6

[William Herrin]

On 10/3/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > If you care to wager, I'll take some of that action. Without
> > a relatively transparent mechanism for IPv6-only hosts to
> > access IPv4-only sites this isn't going to happen. We don't
> > have such a mechanism built and won't have it deployed in 12 months.
>
> What about these two?
> http://www.getipv6.info/index.php/Transitioning:_6to4

Michael,

As mentioned, 6to4 doesn't do what you seem to think it does. Its not
a solution to the problem of IPv6 endpoints trying to talk to IPv4
endpoints.


> http://www.getipv6.info/index.php/Transitioning:_NAT-PT

Looks interesting. There's some version 0.4 user-space software for
Linux which claims to do it and Cisco claims to do it in IOS 12.4
advanced enterprise.

Let me know how it works out for you when you try it in "many to one"
mode. That is, many IPv6 addresses behind 1 IPv4 address, what Cisco
still insists on calling port address translation.

Regards,
Bill Herrin


-- 
William D. Herrin  [EMAIL PROTECTED]  [EMAIL PROTECTED]
3005 Crane Dr.Web: 
Falls Church, VA 22042-3004

Re: Creating demand for IPv6

[William Herrin]

On 10/3/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > As mentioned, 6to4 doesn't do what you seem to think it does.
> > Its not a solution to the problem of IPv6 endpoints trying to
> > talk to IPv4 endpoints.
>
> I see that you did not change anything on that page. Specifically what
> is wrong with the wording below?

Michael,

I could quibble about the description that it "requests dynamic
tunnels." Nothing is requested. Its comepletely stateless. There's no
setup or teardown. It just sends packets that get encapsulated and
decapsulated as they're received. But the description is not
unreasonable.

Where in the description you posted did you read anything that
suggests it allows IPv6 endpoints to communicate with IPv4 endpoints?


> > Looks interesting. There's some version 0.4 user-space
> > software for Linux which claims to do
> You know, you could have added that to the page yourself. In any case, I
> added a pointer to a Cisco product brief that mentions they have
> upgraded NAT-PT to CEF in 12.4.

I generally wait until I've seen something actually work before
documenting how it works.

I haven't dug too deep into NAT-PT, but an obvious question comes to
mind: Why would an ISP deliver an IPv6-only connection plus NAT-PT
(and all the likely problems) with a surcharge for IPv4 instead of
delivering RFC1918 IPv4 + NAT with a surcharge for routable IPv4?
Without looking decades ahead to the waning days of IPv4 when its
desirable to minimize the IPv4 footprint in your network, I haven't
been able to come up with an answer. When I do, I'll take another look
at NAT-PT.

Regards,
Bill Herrin


-- 
William D. Herrin  [EMAIL PROTECTED]  [EMAIL PROTECTED]
3005 Crane Dr.Web: 
Falls Church, VA 22042-3004

Re: Creating demand for IPv6

[Nathan Ward]

On 4/10/2007, at 12:24 PM, <[EMAIL PROTECTED]>  
<[EMAIL PROTECTED]> wrote:

I did not change anything on that page, either. For the
record, that's because I have a screaming two-year-old trying
to use me as a climbing wall right now.


My 10 month-old is soundly sleeping right now so I incorporated your
suggestions into the page.


Michael,

It would also be worth noting that 6to4 <-> 6to4 goes direct over  
IPv4 - not through 192.88.99.1 (or whatever other relay you've chosen).


It's truely stateless, and the concept of client/server is misleading  
- when a 6to4 router transmits an IPv6 packet over IPv4, all it's  
doing is looking at the next-hop to reach that v6 address, and taking  
bytes 3-6 from the IPv6 address and using that as the destination  
IPv4 address. In most cases, the next-hop for 2000::/3 is set to  
2002:192.88:99.1::


So, content providers would be wise to route 2002::/16 at a 6to4  
router they run in-house, so that at least the return path to the  
'customer'/'client'/'end user of their content services' goes over a  
more-or-less identical path as it would if it were IPv4. The content  
provider can run this on any public IPv4 address, and packets aren't  
going to be coming back that way. (RFC1918 would work, but you might  
be blocked by bogon RPFs in some cases).


Teredo is really good in this sense - your client detects which relay  
Teredo packets come from, and caches that as the best relay to use to  
talk to that host. So, you get close-to-IPv4-path for both forward  
and reverse.
So, content providers should run Teredo relays also - their over- 
Teredo performance will be almost the same as their over-IPv4  
performance.


There should be no reason that 6to4 can't do the same thing, I suppose.

--
Nathan Ward

Myanmar Internet turned off

[Steve Gibbard]

There have been several news stories today about Myanmar's government 
turning off the country's Internet connectivity to suppress news coming 
out of the country (for instance: 
http://www.nytimes.com/2007/10/04/world/asia/04info.html?ref=world). 
Doing some poking at it earlier today, here's what I found:


The .MM top level domain has disappeared.  It's served by three name
servers:
;; AUTHORITY SECTION:
mm. 172800  IN  NS  NS-MM.RIPE.NET.
mm. 172800  IN  NS  NS.NET.mm.
mm. 172800  IN  NS  NS0.MPT.NET.mm.

;; ADDITIONAL SECTION:
NS.NET.mm.  172800  IN  A   202.153.125.17
NS0.MPT.NET.mm. 172800  IN  A   203.81.64.20
NS-MM.RIPE.NET. 172800  IN  A   193.0.12.151

ns0.mpt.net.mm is in Myanmar, part of the network of Myanma Post & 
Telecommunication.  It's unreachable.


ns.net.mm is in address space registered to Powerbase DataCenter Services 
(HK) Ltd. in Hong Kong.  It's also unreachable, which makes it difficult 
to confirm whether its physical location matches its registered location. 
It may also be in Myanmar.


ns-mm.ripe.net is in Amsterdam.  It's reachable, but is responding to all 
queries with a SERVFAIL response.  Presumably, this means it hasn't been 
able to get updates from a master server for the .MM domain for long 
enough that its data has expired.


Looking at the rest of Myanmar's connectivity to the outside world, Myanma 
Post & Telecommunication has two IP address blocks registered to it: 
203.81.64.0/19 and 203.81.160.0/20.  Both of those blocks were in the 
global Internet routing table on September 27, but but have not been since 
September 28 (according to daily snapshots of route-views data).  It's 
pretty safe to say that Myanma Post & Telecommunication has completely 
turned off its connection to the outside world.  This is no doubt 
following the example set by the King of Nepal during the coup there a 
couple years ago.


The New York Times story says there are two ISPs in Myanmar.  Myanma Post 
& Telecommunication is the only one with IP addresses registered to a 
mailing address within the country, so I'm not sure who the other one is, 
or what its status is.


-Steve

Re: Creating demand for IPv6, and saving the planet

[Daniel Senie]

At 08:04 PM 10/3/2007, Stephen Sprunk wrote:


Thus spake "Daniel Senie" <[EMAIL PROTECTED]>
A number of people have bemoaned the lack of any IPv6-only 
killer-content that would drive a demand for IPv6. I've thought 
about this, and about the government's push to make IPv6 a reality. 
What occurred to me is there is a satellite sitting in storage that 
would provide such content:


  http://en.wikipedia.org/wiki/Triana_(satellite)

Al Gore pushed for this satellite, Triana, to provide those on 
earth with a view of the planet among its scientific goals. The

Republicans referred to it as an "overpriced screen saver," though
the effect even of just the camera component on people's lives
and how they treat the planet could be considerable.

By combining the launch of Triana with feeding the still images and 
video from servers only connected to native IPv6 bandwidth, the 
government would provide both a strong incentive for end users to 
want to move to IPv6, and a way to get the people of this planet to 
stop from time to time and ponder the future of the earth.


Here's a simple question that applies to every "killer app" that's 
been proposed for IPv6: if you're going to the trouble of making a 
killer app and giving/selling it to the public, why wouldn't you 
include support for IPv4?


The US Government has stated an intention to have all equipment 
supplied to it be capable of IPv6, and networks to run IPv6. 
(http://www.whitehouse.gov/omb/egov/b-1-information.html#IPV6) That 
being the case, this would be an opportunity for the government to 
use something to push that goal along. Clearly there's nothing about 
a screen saver image from L1 that requires IPv6, but the government 
owns Triana, and the government wants to push IPv6 (OK, so the 
government also pushed OSI in the form of GOSIP, and we all know how 
well that worked out).



Virtually every "unique" feature of IPv6, except the number of bits 
in the address, has been back-ported to IPv4.  There is simply no 
other advantage left, and thus no room for apps that "require" IPv6.


Agree all the way around. There's no technological reason to tie 
these items together. There is a political reason, as it fits with 
the agenda of the government to push IPv6 development and deployment.


How the government would prevent proxying of this content into IPv4, 
well, that's another matter. Perhaps the IPv6 evangelists will be 
able to convince Congress to outlaw that at the same time as they 
approve the launch of Triana and provide for the server farm to serve 
the images.


BTW, thanks for bringing this thread back to the question of creating 
demand for IPv6. There's plenty of anti-NAT activity on other 
threads. Some constructive discussion over ways to create incentives 
to deploy IPv6 is worthwhile. The most common argument for deployment 
of IPv6 is fear, as in "the sky is falling." Yeah, we all heard that, 
and have for a decade. Got it. Now, is there some POSITIVE reason to 
push IPv6? Fear is not a positive force.


Dan 

Re: Myanmar Internet turned off

[Suresh Ramasubramanian]

On 10/4/07, Marshall Eubanks <[EMAIL PROTECTED]> wrote:

> Given the 6 hour sampling, I have to assume that there have been
> other short term re-appearances of routes to Burma.
> Whether this is due to internal struggles, accidents, or urgent needs
> for data transfer I cannot say.

I believe the NYT said something about embassies, international
organizations and such being allowed to retain their dedicated
satellite connectivity?

Re: Creating demand for IPv6, and saving the planet

[Mike Leber]

On Wed, 3 Oct 2007, Daniel Senie wrote:
> BTW, thanks for bringing this thread back to the question of creating 
> demand for IPv6. There's plenty of anti-NAT activity on other 
> threads. Some constructive discussion over ways to create incentives 
> to deploy IPv6 is worthwhile. The most common argument for deployment 
> of IPv6 is fear, as in "the sky is falling." Yeah, we all heard that, 
> and have for a decade. Got it. Now, is there some POSITIVE reason to 
> push IPv6? Fear is not a positive force.

Ok, I'll bite and throw out a wacky idea I've been mulling over.

As the data at http://bgp.he.net/ipv6-progress-report.cgi shows for the
IPv6 and IPv4 nameserver tests, some of the time IPv6 connectivity is
*faster* than IPv4 connectivity (66 out of 264 test cases), because of
network topology differences due to different peering and transit
relationships between IPv4 and IPv6.

So you could write a download accelerator for your browser that checked
IPv6 vs IPv4 connectivity and used whichever was faster.

With only 3 percent of neworks running IPv6 this idea is a little early,
still it would be a hilarious browser plug-in.  You could imagine it might
even have a little "IPv6 accelerator" icon that shows up in your status
bar when you've switched on the nitro.

(hehehe, shaving off that extra few ms of latency, yo!)

Mike.

+- H U R R I C A N E - E L E C T R I C -+
| Mike Leber Wholesale IPv4 and IPv6 Transit   510 580 4100 |
| Hurricane Electric Web Hosting  Colocation AS6939 |
| [EMAIL PROTECTED]   http://he.net |
+---+