Subject: The point is to change it: Was: IPv4 depletion makes CNN

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 30 May 2010 18:52:44 -0400

We keep coming back to the same old problem and the same reasons we
are going to hope it solves itself without having to change anything.

1) Its the wrong type of pain

IPv4 exhaustion does cause problems, but not really enough problems or
immediate enough problems to create an incentive to move away from the
IPv4 Internet.

It really does not matter very much to the typical Internet user if
there are other people unable to join the party. It matters even less
to them if those people are in far away countries.

2) NAT-NAT IPv4 still beats IPv6

Even with the restrictions of carrier NAT, most Internet users are
going to prefer an Internet connection that gives access to the
millions of IPv4 hosts than the hundreds of IPv6 hosts.

This is an adoption trap. Nobody is going to move to IPv6 unless the
functionality is superior to IPv4.

Saying that IPv6 is X years behind is to miss the point.

3) There is no ask

ISOC and others are very good at putting out these stories warning
about the imminent IPv4 exhaustion.  But this is wasted effort when
the message reaches people who can do nothing in response.

For a message to be effective, there has to be an ask, there has to be
something concrete that the audience can do in response.

As before I will suggest how I would address the issue:

1) Branding

Every technology company that has wanted to establish an
infrastructure to support their product has used branding as leverage.
Remember 'Novell Ready', 'Entrust Ready', 'Windows Vista Ready'?

We need an Internet Next Ready. And when consumers see that brand they
need to know that what they are getting is going to work with the next
generation Internet. Demanding 'Internet Next Ready' in new products,
in Internet service is the ask.

2) Design for deployment

People are not going to use IPv6 if it takes the slightest effort on
their part. People are not going to switch their home networks over to
IPv6 if it means a single device on the network is going to stop
working. In my case it would cost me $4K to upgrade my 48" plotter to
an IPv6 capable system. No way is that going to happen till there are
$50 IPv6 plotters on EBay.

I try to do as little management of my home network as possible. For
the architecture to be acceptable it has to be totally transparent to
me. Otherwise carrier grade NAT is going to be preferable as at least
that is going to work.

3) Create incentives

Even with branding, the incentives have to make sense. Merely having
access to the IPv6 Internet available is not going to cause people to
use it. Pretty much every host on the Internet can use IPSEC at this
point. The portion that use it is ~ 0%.

The way that I plot out a campaign is to list every stakeholder that I
need to take action. I consider the positive/negative balance sheet
from their point of view. I look at the incentive they have to take
action and how they are to get the message that they need to take
action.

Now I can draft out an architecture that would have the necessary
properties quite easily. And so could many others on this list. But
that would be a mistake. In order to get buy in from all the people
whose buy in is needed, they have to be involved at the design stage.

Having the had the opportunity to be involved is not the same thing.

---

From: Olivier MJ Crepin-Leblond <[email-masked]>
Date: Tue, 01 Jun 2010 17:57:34 +0100

> $50 IPv6 plotters on EBay.

Sorry, but that's a red herring.
You're speaking about IPv4 decommissioning, not IPv6 implementation.
Implementing IPv6 will do nothing to your local plotter.Your computer
will keep addressing IPv4 to it.
Nothing stops you from always running dual stack at home, with your IPv4
behind your NAT/PAT.

Have you tried implementing IPv6 at home?

Kind regards,

Olivier

-- 
Olivier MJ Crépin-Leblond, PhD
http://www.gih.com/ocl.html

---

From: todd glassey <[email-masked]>
Date: Tue, 01 Jun 2010 10:05:21 -0700

> immediate enough problems to create an incentive to move away from the

AMEN, and ARIN could recover any number of multiply issued /8's to 
corporate entities who acquired blocks by merger, like HP for instance. 
The have TANDEM's DEC's Compaq's and HP's /8's and do they need anywhere 
near that many IPv4 addresses?

NO...

So the issue is ARIN and its sloppy operating policies - and yes Cathy 
(their attorney) has heard this from me already.

> to them if those people are in far away countries.

Duh... the only people who need a fully flat-routed world are the 
Standards Practitioners.

> millions of IPv4 hosts than the hundreds of IPv6 hosts.

Yep

> in Internet service is the ask.

yes but this then is a marketing effort to convince people (the end 
users) that they need this new gizmo more than the old gizmo and not a 
technological one.

> their part.

Yep...

> People are not going to switch their home networks over to

Yep, meaning that NAT and not IPv6 is the solution.

> point. The portion that use it is ~ 0%.

This speaks all that needs to be said here, so unless there is some real 
reason that the Internet is going to break unless IPv6 is rolled out 
there is no reason to do it.

Again - IPv4 and NAT are a very reasonable solution as it network 
segmentation.

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: [email-masked]
Date: Tue, 01 Jun 2010 10:19:00 -0700 (PDT)

> Sorry, but that's a red herring.

No, not really. Unless you're willing to fully upgrade to IPv6, you're
talking about continuing to use NAT for the legacy IPv4 devices. And that
buys you into substantial complexity in terms of routing and configuration.

> Have you tried implementing IPv6 at home?

As a matter of fact I have. It was a total disaster and after spending several
days trying to get it to work I gave up. The specific problems I had were with
DNS queries being blocked for mysterious reasons and hairpin routing
configuration problems, but the simple fact that such esoteric issues had to be
dealt with by a home network admin sort of says it all.

As I've stated previously, I believe the main piece that's missing is a
SOHO-grade router that has full IPv6 support, 6to4 support, full
IPv4/NAT/firewall support, plus a readonably intuitive GUI to administer it
all. If such a product exists I continue to be unaware of it.

				Ned

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Tue, 1 Jun 2010 23:12:59 +0100

> all. If such a product exists I continue to be unaware of it.

I agree.

With the exception (grrrr) of a non-configurable packet filter (besides the NAT function and per-port-based IPv6), Apple's Airport Extreme and Time Capsule do IPv6 very nearly out of the box (it was disabled by default because a load of "Security researchers" took issue with exposing computers to the IPv6 Internet by default).  In about ten clicks, and assuming your Internet connection is provided by ethernet to a global IPv4 address, these base stations will set up and advertise a 6to4 routed block for your network, and handle transparent v4/v6 DNS from one proxy.  They're supposed to be able to handle custom tunnels, but bugs prevent it from working; it also works as a native router, a host on an existing v6 network, and link-local for configuration (no more slipping/forgotten netmasks).

So all in all, I'm quite pleased with them, and they're the reason I decided IPv6 was no longer hard for anybody.  No doubt there are others out there, or should be (IE, from ISPs) and of course there's Teredo or custom protocols if you want to stay behind an existing legacy NAT.  And of course, if you want to, you can build your own with a Linux box, though I agree that sort of misses the deployability aspect, and is more toward the enthusiast, though that's how my original setup went for my DSL provider.

Cheers,
Sabahattin

---

From: Douglas Otis <[email-masked]>
Date: Tue, 01 Jun 2010 15:22:03 -0700

On 6/1/10 9:57 AM, Olivier MJ Crepin-Leblond wrote:
> Implementing IPv6 will do nothing to your local plotter. Your computer
By accident when solving a network drop-out problem within a congested 
wireless environment, installing an airport extreme router also offered 
IPv6 over an IPv4 ISP.  Everything just worked.
When later changing providers, the cable modem needed extensive tweaking 
before everything worked, which then lowered throughput by about 35%.  
To overcome this, several commodity routers were tried, but they were 
unable run DHCP once the modem's NAT was disabled.   Double NATs cause 
additional breakage.  Once again, the airport extreme just worked.  This 
was learning the hard way it seems.

Unless one is careful, one might find themselves using IPv6 without 
their knowledge, both globally and locally.  Capturing local traffic 
showed several applications already making use of the local IPv6 address 
space.   And I'd even wager that an IPv4 plotter would work,  since an 
HP IPv4 printer does.

-Doug

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Jun 2010 10:31:13 +1000

In message <[email-masked]>, Phil
> 2) NAT-NAT IPv4 still beats IPv6

But we are not talking NAT-NAT IPv4 vs IPv6.  We are talking
NAT-NAT/Distributed NAT IPv4 with plain IPv6.

> millions of IPv4 hosts than the hundreds of IPv6 hosts.

If you present it to them that way then they would agree with you.
If you present it to them as NAT-NAT along or NAT-NAT plus IPv6 you
will get a different answer especially when IPv6 is not more
complicated than IPv4 is today.

> in Internet service is the ask.

Most of the equipment they already have is IPv6 ready.   It's the
home router that isn't.
 
> $50 IPv6 plotters on EBay.

Turning on IPv6 does not mean that you have to turn off IPv4.  You
can continue to use IPv4 until you no longer need to use it.

> me. Otherwise carrier grade NAT is going to be preferable as at least

Except for the additional things that it breaks.
 
> point. The portion that use it is ~ 0%.

Actually it is well above zero and lots of people are using it
without being aware that they are using it.  If you turn on IPv6
on your servers you will get traffic.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Wed, 2 Jun 2010 10:39:01 +0300

Nice to hear "just worked" in the context of IPv6. Did your router give you just an IPv6 address, or also an IPv4 address?  If both, does the IPv6 address ever get anywhere on the Internet, or is it always NATted?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Douglas Otis
Sent: Wednesday, June 02, 2010 1:22 AM
To: [email-masked]
Subject: Re: The point is to change it: Was: IPv4 depletion makes CNN

-Doug

Scanned by Check Point Total Security Gateway.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 02 Jun 2010 01:47:38 -0700

> Nice to hear "just worked" in the context of IPv6. Did your router give you just an IPv6 address, or also an IPv4 address?  If both, does the IPv6 address ever get anywhere on the Internet, or is i…
The router appears to use RFC3056, with the external IP address in the 
range for 6to4 that was noticed when visiting APNIC.NET.

-Doug

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Jun 2010 10:36:32 -0400

> all. If such a product exists I continue to be unaware of it.

That is my conclusion as well.

But the basic principle for me is that I have to put no effort into
this changeover at all as a network admin. Its got to be no more than
a replacement of one gateway box with another.

Expecting more is futile as the power users are not going to be early
adopters for single stack IPv6. We are the ones who are going to want
IPv4 connectivity the longest. The target market for IPv6 has to be
the less demanding users for whom a full IPv6 connection and a NAT-ed
IPv4 are going to serve perfectly well.

I am not going to tell any of my friends or family to move to IPv6
unless it is absolutely guaranteed to be painless. Otherwise I am
going to be the one doing long distance tech support.

-- 
Website: http://hallambaker.com/

---

From: joel jaeggli <[email-masked]>
Date: Wed, 02 Jun 2010 11:47:08 -0700

On 2010-06-02 07:36, Phillip Hallam-Baker wrote:
> On Tue, Jun 1, 2010 at 1:19 PM, Ned Freed<[email-masked]>  wrote:
>

D-link Dir 825

http://www.dlink.com/products/?pid=DIR-825

real firewall knobs, ipv6 in the gui etc... It think all their 
"high-end" home router small business devices are getting features as 
they get replaced.

I have one deployed, screenshot is here:

http://www.flickr.com/photos/joelja/4663980030/

now would people please stop on this subject, the manufacturers know how 
to build this stuff.

---

From: Fred Baker <[email-masked]>
Date: Wed, 2 Jun 2010 15:21:24 -0700

> in Internet service is the ask.

http://www.ipv6ready.org/

---

From: Mark Andrews <[email-masked]>
Date: Thu, 03 Jun 2010 08:44:20 +1000

> now would people please stop on this subject, the manufacturers know how 

The only reference to IPv6 is "IPv6 Gold"

Does that mean that it does PD?  I don't know and I'm not about
to wade through the 135 page test spec for DHCPv6 to find out.
Does it do DHCPv6 client / server.

---

From: joel jaeggli <[email-masked]>
Date: Wed, 02 Jun 2010 16:02:30 -0700

On 2010-06-02 15:44, Mark Andrews wrote:
> Does that mean that it does PD?

It does not.

> I don't know and I'm not about

It has both dhcpv6 client and server. it makes the assumuption that if 
you want to assign v6 nameservers that you'll do so with stateful dhcpv6.

the product is closing in on a year old so I imagine the product 
managers fixed the feature set in stone rather a long while ago.

---

From: Martin Rex <[email-masked]>
Date: Thu, 3 Jun 2010 01:09:54 +0200 (MEST)

> all. If such a product exists I continue to be unaware of it.

While I believe that many many millions of SOHO-grade routers out there
are not capable of that and will remain so for easily 5 more years,
they're are fairly easy to "replace".  Change your ISP (after two years)
and you'll get a new router almost free from you new ISP, at least here
in Germany.  And they've made configuring these Routers reallllly easy
for non-techies!  Some ISP are down to a 12 alphanum code that makes
the router download its entire configuration from the ISP.

What about the IPv6 capabilities and configurability of devices that
are much more difficult to configure or update and much more expensive
to replace?

 - Game consoles used for online gaming (XBox,PSP,WII)?
 - Internet-capable Flatscreen-TVs
 - Set-Top boxes (e.g. feature-enhanced DVB-C of DVB-S Receivers)
 - SOHO Network attached storage (NAS)
 - other internet enabled home appliances (e.g. refrigerator)

-Martin

---

From: joel jaeggli <[email-masked]>
Date: Wed, 02 Jun 2010 16:27:08 -0700

>   - other internet enabled home appliances (e.g. refrigerator)

Let's face it, your Internet Fridge while not OSI compliant unlike your 
Decnet Phase IV fridge, is a bad idea that will be consigned to history, 
it will still keep beer cold.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 03 Jun 2010 09:40:27 +1000

> managers fixed the feature set in stone rather a long while ago.

So you think I should expect support for a option that was specified
in 2003 in products that first shipped in 2009?

Mark

---

From: joel jaeggli <[email-masked]>
Date: Wed, 02 Jun 2010 16:43:11 -0700

> in 2003 in products that first shipped in 2009?

RFC 1884 was December 1995 and we're still bitching and moaning about 
it... QED.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 03 Jun 2010 09:48:29 +0300

Martin,

>  - other internet enabled home appliances (e.g. refrigerator)

You could view these as not problems -- they are good reasons to keep 
your network in dual stack for quite some time.

(But some game consoles do get frequent firmware updates from the 
network, as some people with PS3s have found out. So do set-top boxes. 
And AFAICT a common application of Internet in the DVD player/TV space 
is firmware upgrades from the network -- how else would my Blue Ray 
player play the latest Java-"enhanced" disks? I'll postulate that a good 
fraction home entertainment equipment either can upgrade itself or has a 
very short lifetime anyway.)

Jari

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 06 Jun 2010 14:39:13 -0700

Sounds like you'll need to be looking up market, you're not really
looking for a soho router at the point where you've got multiple
external providers.

This device and it's ilk represted the ipv6 functionality availble in a
circa mid to late 2009 home router with a retail price of $100-$150.
They are pretty good devices.

If you're comparing them to a sonic wall tz you're not really comparing
the same class of device. by your own admission the later is inadequate
so I'm not sure why you'd even bring it up.

joel

On 06/06/2010 11:39 AM, Ned Freed wrote:
> Alternate email client usage fail. My apologies.
> 
>                 Ned
> 
>> (offlist)
> 
>> This box may have adequate IPv6 support. (Or it may not - several
>> people have
>> raised issues with it's capabilities. Personally, I lack sufficient
>> operational
>> experience with IPv6 to know one way or the other.)
> 
>> But it's severely deficient in terms of IPv4/NAT/firewall
>> capabilities. In
>> particular, while it has decent NATPT support, there is no indication
>> it cannot
>> handle multiple WAN-side IPv4 addresses and/or 1:1 NAT. The firewall is,
>> according to several reviews I've seen, inadequate on the IPV6 side.
> 
>> This puts it in the same category as the Apple Airport line and the
>> Linksys
>> RVS4000 - probably adequate for personal home use. But in no way,
>> shape or form
>> adequate for SOHO use. I was very clear I was talking about the
>> latter, not the
>> former.
> 
>> I'm waiting for an existence proof of the truth of this statement. So
>> far I
>> haven't seen one. The closest I've seen so far is the Sonicwall TZ
>> line, but
>> while it's very capable on the IPv4/NAT/firewall side of things, it's
>> IPv6
>> support appears inadequate - no 6to4, no IPv6 firewall capabilities, etc.
> 
>>                 Ned
>

---

From: [email-masked]
Date: Sun, 06 Jun 2010 11:39:15 -0700 (PDT)

Ned

> This box may have adequate IPv6 support. (Or it may not - several people have
> raised issues with it's capabilities. Personally, I lack sufficient operational

> But it's severely deficient in terms of IPv4/NAT/firewall capabilities. In
> particular, while it has decent NATPT support, there is no indication it cannot

> This puts it in the same category as the Apple Airport line and the Linksys
> RVS4000 - probably adequate for personal home use. But in no way, shape or form
> adequate for SOHO use. I was very clear I was talking about the latter, not the
> former.

> I'm waiting for an existence proof of the truth of this statement. So far I
> haven't seen one. The closest I've seen so far is the Sonicwall TZ line, but
> while it's very capable on the IPv4/NAT/firewall side of things, it's IPv6

---

From: [email-masked]
Date: Sun, 06 Jun 2010 08:56:06 -0700 (PDT)

(offlist)

				Ned

---

From: [email-masked]
Date: Sun, 06 Jun 2010 16:17:04 -0700 (PDT)

> looking for a soho router at the point where you've got multiple

Who said anything about multiple external providers? All I'm talking about is
support for a small number of static IPs on a single network interface. Like
you'd need to run, say, a couple of small scale servers. This is NOT high end
in any way, shape, or form.

> They are pretty good devices.

In your opinion, perhaps. But 10 years ago I bought a Sonicwall SOHO router
with all of the capabilities - except IPv6 support - I'm talking about here. I
think it cost around $250. Is it really too much to ask that, 10 years later,
for a comparable device with decent IPv6 support added?

> so I'm not sure why you'd even bring it up.

The Sonicwall TZ 100 is available for $289. The D-link unit you are fond of
lists for around $160, the Airport Extreme for around $179, the Linksys RVS4000
is the cheapie in the group at around $110. Nevertheless, these are hardly in
vastly different price classes.

But let's assume, for the moment, that they are - that the extra $100-$200 is a
really big deal. So what? My point stands - you have yet to identify anything -
even an "upscale" box - that meets my stated criteria where "must be dirt
cheap" was conspicuous by its absence.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Mon, 07 Jun 2010 15:49:53 -0400

--On Sunday, June 06, 2010 14:39 -0700 Joel Jaeggli
<[email-masked]> wrote:

> Sounds like you'll need to be looking up market, you're not
> really looking for a soho router at the point where you've got
> multiple external providers.
> 
> This device and it's ilk represted the ipv6 functionality
> availble in a circa mid to late 2009 home router with a retail
> price of $100-$150. They are pretty good devices.
> 
> If you're comparing them to a sonic wall tz you're not really
> comparing the same class of device. by your own admission the
> later is inadequate so I'm not sure why you'd even bring it up.

Joel,

Ned has already responded to part of this and I won't repeat,
but let me respond to your last comment from my perspective (I
assume a similar network with a few servers... but I do have two
external providers).  Because of the servers, both Ned and I are
clearly in the SOHO world, not the "client only" residential
one, as my ISPs remind me by having me write checks every month
for "business service" and "multiple static addresses" that
total around an order of magnitude more than my neighbors are
paying for equivalent bandwidth.  But, while limited in size and
scope, they are (or at least mine) are real networks, not a VPN
parasite on an enterprise network somewhere that does the _real_
routing, etc.

Devices like the Linksys RV082 and, with a feature set that is a
little larger in some areas and smaller in others, the SonicWall
TZ and its predecessors, _do_ provide adequate support for
networks of that type when they are running IPv4-only.  Foe
example, the RV082, perhaps because the designers couldn't
figure out how to do better in a box of that size and
complexity, provides for multiple public external addresses pnly
via 1:1 NAT and the SonicWall (at least the earlier one I have)
actually understands about public addresses. 

FWIW, I've got some fairly serious (enterprise class or above,
not SOHO class), if old, router iron lying around here.  But,
even if the vendor were providing good quality IPv6 software and
support for it (they aren't), the amount of effort needed to set
it up for this type of network would probably be too expensive
(which is most of why it got retired years ago).

My belief is that we have a serious IPv6 marketing and
transition problem until and unless we can get a level of
functionality for IPv6 (and, really, for IPv4/IPv6 mixtures of
the sorts that Ned's notes imply) at a level of investment
roughly equivalent to the costs we are now paying for IPv4
alone.   I want to stress that "level of investment" and terms
like "expensive" are measured in requirements for knowledge,
maintenance, configuration fussing, etc., not just hardware.
They also include some important issues about support costs on
the vendor/ISP side: if an ISP sells a "business IPv6 service"
with certain properties and customers get into trouble, that ISP
is itself in trouble if the support requests require third-level
or engineering/design staff involvement to understand or
resolve.  When the hardware costs we are talking about are in
the same range as one month's connectivity bills (and all the
numbers you and Ned mentioned are, at least for me), they just
wash out and disappear compared to aggravation, fussing, and
other sysadmin costs.

    john

---

From: Douglas Otis <[email-masked]>
Date: Wed, 09 Jun 2010 12:42:33 -0700

> wash out and disappear compared to aggravation, fussing, and
IMHO, it would be a mistake to expect low end routers targeting home and 
small office environments to eventually include features for handling 
multiple IPv4 addresses in conjunction with an IPv4 to IPv6 transition 
strategy, largely for the reasons you give.   When multiple providers 
are involved, some choices are available for multiple IPv4 addresses 
where devices terminating a provider's network are connected through a 
vlan switch with trunking.  Or terminated with a selection of mid-range 
routers ~$400/$50 new/used price range, such as cisco 871 or 2600.   
Instead of expecting a company's support to deal with with involved 
configurations, solutions are increasingly met by co-location services, 
or VPS where the providers offer network/power redundancy,  dual stack 
rout-ability, and support expertise.

An automatic 6to4 tunnel for an isolated IPv6 network,  routes on a 
per-packet basis to a border router in another IPv6 network over IPv4 
infrastructure.  Tunnel destinations are determined by the IPv4 address 
of the border router extracted from the IPv6 address starting with the 
prefix 2002::/16 having the format 
2002:/border-router-IPv4-address/::/48, which likely makes this a 
function of the ISP.  When IPv6 is available, each device becomes 
accessible with unique IP addresses.  A conservative approach for scarce 
IPv4 addresses is to associate dedicated servers/services with specific 
ports of a single global address, a feature supported by nearly all 
commodity routers.  Whenever accessing IPv6 networks over the Internet 
becomes imperative, ISPs will suggest boilerplate solutions.  However, 
it seems unlikely these will include anachronistic use of IPv4 addresses.

-Doug

---

From: [email-masked]
Date: Wed, 09 Jun 2010 13:19:15 -0700 (PDT)

> multiple IPv4 addresses

Except that there is no "eventually" here. This class of device already 
supports multiple IPv4 addresses and 1:1 NAT, for the simple reason that a lot
of such setups depend on having such support. This has been true for many
years.

The problem with this class of device isn't the lack of support for multiple
IPv4 addresses, it's the lack of support for IPv6.

> in conjunction with an IPv4 to IPv6 transition
> are involved,

Again with the multiple providers strawman. Nobody is talking about multiple
providers and failover and so on here. This truly is a different level of
service.

> some choices are available for multiple IPv4 addresses

All of which fals FAR outside the range of service this discussion is about.

> it seems unlikely these will include anachronistic use of IPv4 addresses.

And so, having no other argument to make, we resort to pejoratives? 

Calling small business use of a small number of IPv4 addresses "anachronistic"
doesn't change the fact that this is a widespread practice fully supported by
an ample number of reasonable quality router products. And you're not going to
get IPv6 deployed in such cases without a drop-in replacement that adds IPv6
support to what's already there.

				Ned

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 09 Jun 2010 15:40:19 -0700

> support to what's already there.

this is cute ned but your assertion that this device can't route for a
interior public prefix was just plain wrong. perhaps you should actually
get one and try it?

---

From: Douglas Otis <[email-masked]>
Date: Wed, 09 Jun 2010 16:29:33 -0700

On 6/9/10 1:19 PM, Ned Freed wrote:
>> When IPv6 is available, each device becomes
Sorry, this was in reference to an approach based on passed 
assumptions.  The inflection point for when multiple IPv4 addresses at 
an access point becomes anachronistic will occur with an IPv6 
connectivity imperative driven by the lack of IPv4 addresses.

In most small office/home office (SOHO) cases, a single IPv4 address is 
both sufficient and well supported for use with IPv4 and IPv6 remote 
networks.  Additional IPv4 global addresses for an access point will 
likely involve recurring costs due to complexity and dependence upon 
this scarce resource.  The inflection point for when multiple IPv4 
addresses at an access point become anachronistic occurs with an IPv6 
connectivity imperative.  Perhaps the US will delay acceptance of this 
imperative, long after the rest of the world has embraced IPv6.  After 
all, US, Liberia, and Burma have yet to adopt metric measures. :^)
> support to what's already there. 
Clearly, with skill and non-commodity equipment, a configuration 
supporting multiple IPv4 addresses at an access point can be implemented 
in conjunction with IPv6.  This could be practical when many within an 
organization are affected, but would not involve commodity low-end 
routers.  Such configurations will remain rare due to IPv4 resource 
consumption, and greater support complexity.  Fortunately, it remains 
easy to adopt the resource conservative IPv4 configurations supported by 
commodity routers when obtaining IPv6 connectivity.  Why should the IETF 
advocate an increased IPv4 use that lacks benefit once a network has 
been configured?

-Doug

---

From: [email-masked]
Date: Wed, 09 Jun 2010 16:00:34 -0700 (PDT)

> interior public prefix was just plain wrong.

That statement may be wrong, but since (a) I never said any such thing and (b)
AFAICT this is completely disjoint from the issue of supportt for multiple IPv4
addresses and similar IPv4 facilities, I fail to see the relevance.

> perhaps you should actually get one and try it?

I don't have to. D-Link has this cute web-based emulator that lets you try out
their stuff without having to buy it. I used this emulator, available at

    http://www.support.dlink.com/emulators/dir825_revB/202NA/login.html

to check and see if this device supports multiple IPv4 addresses and 1:1 NAT.
Unless I'm missing something, it does not. It does have NATPT, but that's not
sufficient.

Feel free to prove me wrong by pointing me at the pages where the support for
multiple IPv4 addresses lives and related firewall capabilities lives.

				Ned

---

From: [email-masked]
Date: Wed, 09 Jun 2010 17:57:30 -0700 (PDT)

> connectivity imperative driven by the lack of IPv4 addresses.

But things have to get to that point first. I for one am not especially
sanguine about IPv4 address scarcity forcing sensible behavior soon enough.
Especially given the major holes in IPv6 device support we've been discussing.

> networks.

First of all, I disagree with this assessment, and cite as evidence the
widespread availability of support for mutiple addresses in SOHO-class
firewalls and related equipment. Again, why is this feature present in so many
SOHO-class router/firewalls and has been present for the past 10 years at least
if nobody out there uses it?

> Additional IPv4 global addresses for an access point will
> this scarce resource.

True. But the current recurring costs are far less than the effective costs of
all the gyrations you have to go through with proxies and whatnot when you try
and make it all work with NATPT.

I note in passing that this might have played out differently had we gotten SRV
record support in place for all protocols a lot sooner. But without it for HTTP
in particular you're faced with the need for multiple port 80s in a lot of
cases.

> The inflection point for when multiple IPv4
> connectivity imperative.

Yes, but the trick is getting things to that point.

> Perhaps the US will delay acceptance of this

That may indeed be the case, but I must say Hardly a fair comparison for a lot
of venues. It's always easier to deploy new infrastructure when there's
relatively little old infrastructure that has to coexist or be replaced.

> in conjunction with IPv6.

Of couse it can. But that's precisely the point - neither the skill nor the
non-commodity equipment are available in most cases. And even when they are, a
lot of people, like myself, run the costs versus benefits and IPv6 ends up
losing.

> This could be practical when many within an

More strawmen. We're not talking about increased IPv4 use, but rather decent
support for existing, long-deployed IPv4 use. If you seriously think you can
get people to dump their existing setups in favor of somethign that is  a major
PITA to deal with and offers no immediate benefit, well, I have a couple of
bridges available at fire sale prices.

				Ned

---

From: Michael Dillon <[email-masked]>
Date: Thu, 10 Jun 2010 15:44:43 +0100

> Unless I'm missing something, it does not. It does have NATPT, but that's not

I always cringe when I see such discussions hinging around what an
Internet gateway
box "supports". The word "supports" is such a weasel word which makes minor
imperfections that are easily fixed seem like major problems. What is
"supported"
is usually just the set of the features that the manufacturer wants to
document and
publish. Devices often have unsupported features that work fine so the question
of whether or not a feature is "supported" has more to do with whether
technically
incompetent people will feel comfortable using it.

Instead, I think it is better to look at what features *EXIST* for the
platform and
what subset of those features are IMPLEMENTED. Many Internet gateway boxes
are based on an embedded Linux platform, so just about any IPv6 feature that
you can imagine EXISTS and whether or not it is implemented is primarily down
to the will of the manufacturer. There was a time when RAM capacity was also
a limiting issue but I think that time has passed.

Nowadays, if an Internet gateway lacks some feature that is widely implemented
on Linux, then it is a minor imperfection that should be easy to fix
if only people
will COMMUNICATE DIRECTLY WITH THE MANUFACTURER, not through the
press and Internet mailing lists.

Yes, I am aware that not all Internet gateway boxes are based on Linux, but if
that creates a barrier to implementing features like IPv6, then the marketplace
can sort out that issue.

--Michael Dillon

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 10 Jun 2010 08:38:54 -0400

> Especially given the major holes in IPv6 device support we've been

Try 'desirable'.

Sticking to IPv4 till the last minute and letting everyone else make
the necessary investment to support the transition is the 'sensible'
approach for most parties.

The Internet has a billion users and it is now impossible to change it
without putting a great deal of thought into the incentives for
co-operation.

> in particular you're faced with the need for multiple port 80s in a lot of

And the number of protocols is exploding due to Web Services. We now
have far more than 64K protocols in use. The only reason we have not
exhausted the ports is that in the modern Internet everything has to
be layered on port 80 or 443.

What I would like to see the IETF do is to produce a new architecture
document that tells application and Web Service designers how they
should be using the Internet. In my view DNS+SRV should become the
only way that Web services are located (I do not think the extra
capabilities of NAPTR are necessary or even useful for service
discovery).

At the moment we have the OpenID people who currently have five
service discovery mechanisms, none of which use the DNS properly. And
they are not the only group that is merrily creating entropy that is
going to have to be serviced.

We also have a similar issue with the use of XML, there the problem is
that there are four different ways to achieve a certain aim and we
spend a year arguing about which one to pick each time we start a
working group. What I like about RFC822 style headers is not that they
are the best way to move metadata but that they are used in the same
way in every protocol.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 10 Jun 2010 14:48:26 -0700

On 6/9/10 5:57 PM, Ned Freed wrote:
>  I note in passing that this might have played out differently had we
>  gotten SRV record support in place for all protocols a lot sooner.
>  But without it for HTTP in particular you're faced with the need for
>  multiple port 80s in a lot of cases.

Disagree.  HTTP is a bad example, since it allows canonical names to be 
replaced with a name offered by clients for supporting name based 
virtual hosts.   In other words, a single port supports thousands of 
websites. :^)

> > supporting multiple IPv4 addresses at an access point can be
> > implemented in conjunction with IPv6.
>
>  Of couse it can. But that's precisely the point - neither the skill
>  nor the non-commodity equipment are available in most cases. And
>  even when they are, a lot of people, like myself, run the costs
>  versus benefits and IPv6 ends up losing.

Agreed, but that changes once IPv6 becomes an imperative for these 
services, such as websites.  At that point, its easier to scale a 
transitional solution when using fewer IPv4 addresses.  As such, those 
few wishing to retain multiple IPv4 addresses lacking IPv6 connectivity 
are likely the last to adopt IPv6.

> > Fortunately, it remains easy to adopt the resource conservative
> > IPv4 configurations supported by commodity routers when obtaining
> > IPv6 connectivity.  Why should the IETF advocate an increased IPv4
> > use that lacks benefit once a network has been configured?
>
>  More strawmen. We're not talking about increased IPv4 use, but
>  rather decent support for existing, long-deployed IPv4 use. If you
>  seriously think you can get people to dump their existing setups in
>  favor of something that is  a major PITA to deal with and offers no
>  immediate benefit, well, I have a couple of bridges available at fire
>  sale prices.

I still have my English standard spanners, but they are seldom used.  
The impetus to change occurs after IPv6 becomes an imperative, such as 
doing business with a region dependent upon IPv6.  After that, 
complaints related to NATs will fade, and support for IPv4 will be seen 
as the PITA.  The inflection point for this may move faster than imagined.

-Doug

---

From: [email-masked]
Date: Thu, 10 Jun 2010 15:12:05 -0700 (PDT)

> virtual hosts.   In other words, a single port supports thousands of

True but irrelevant. The issue isn't support for multiple web sites, it's
support for multiple servers. Virtual hosts are fine as long as everything
you've got runs under the same web server and on the same hardware. But in many
cases things don't work this way. Let's see. I'm running at least seven
different pieces of software right now that include a web server component.
Now, not all of them provide public services, and for those it doesn't matter
that they're not on port 80. But three of them do provide public services.

Of course redirects and proxies provide a means of getting around these
limitations. But now you're talking about a substantial increase in application
and configuration complexity. Multiple IPs are a lot simpler and easier to
manage.

> are likely the last to adopt IPv6.

With all due respect, I think you need to go read up on pareto optimality and
it's implications for the transitions you claim are inevitable as IPv4
addresses become more scarce.

> I still have my English standard spanners, but they are seldom used.

Major analogy fail. Again, your assertion was that what I'm after involves
increased IPv4 use. This is simply false.

> as the PITA.  The inflection point for this may move faster than imagined.

In other words, the way you see this unfolding is that once there's a
significant IPv6-connected base somewhere, probably in some emerging market,
somebody will view it as  practical to deploy services that can only be reached
by IPv6. As more and more of this happens, it will create a need for everyone
to have IPv6 connectivity, which will then lead to more IPv6-only services, and
so on.

If this is accurate, I think you need to go back and reread John Klensin's
recent messages for why this scenario really isn't all that likely to unfold
the way you think.

				Ned

---

From: Mark Andrews <[email-masked]>
Date: Fri, 11 Jun 2010 10:17:24 +1000

In message <[email-masked]>, [email-masked] w
> recent messages for why this scenario really isn't all that likely to unfold

Turn off the root servers IPv4 address and see how fast people
adapt. :-)

Seriously, I do think it is time that the root and TLD's had IPv6
only name servers.  I'm not advocating IPv4 be turned off on them
yet.

Mark

---

From: John C Klensin <[email-masked]>
Date: Thu, 10 Jun 2010 22:32:56 -0400

--On Friday, June 11, 2010 10:17 +1000 Mark Andrews
<[email-masked]> wrote:

> 
> In message <[email-masked]>,
> [email-masked] w rites:
>> If this is accurate, I think you need to go back and reread
>> John Klensin's recent messages for why this scenario really
>> isn't all that likely to unfold the way you think.
>> 
>> 				Ned
> 

Mark,

I hate to say this, but that is silly, smiley or not.  

Because this may be an example of some of the "force a
transition" ideas that are going around, let's examine what
would happen if it were done.  This analysis more or less
applies to any "cut off some service to force folks onto IPv6"
strategy and is hence worth examining even if we understand that
cutting off the IPv4 root servers is not realistic.

The typical users of the Internet don't use the root servers
directly at all.  They use, exclusively, some full-service
forwarder(s) that might interact with the root servers.  Those
forwarders belong to ISPs, enterprises, etc., and the lusers
think they have contracts for services with those entities.  So,
now, some major piece of infrastructure that, from the user's
perspective is a critical resource covered by the service is
converted to IPv6-only or otherwise made unavailable.  What
happens next is pretty obvious: the provider copes or sees happy
paying customers swap themselves out and their lawyers in.
Using the root servers as an example, "provider copes" would
most naturally take one of two forms:

	(1) Provider sets up an IPv6 server that is capable of
	serving out the root zone (from a cache and and queries
	as needed) to the forwarders who keep serving the users
	with IPv4 DNS.  Net effect on IPv6 deployment: just
	about zero.  Net effect on the DNS: very low or zero.
	
(2) Provider adjusts the local configuration file for the
location of the root zone to point to someone who will serve out
a root zone in IPv4.  Note "a root zone" rather than "the root
zone".  I hope I don't have to explain the difference to anyone
reading this list, but I'm sure I don't have to explain it to
you.  Net effect on IPv6 deployment: zero or worse because even
more credibility will have been lost (for IPv6 and the
intelligence of various institutions).  Net effect on the DNS:
significant and really bad... multiple roots or dubious (or at
least variable) authority.  DNSSec basically has to be turned
off to make that work.  

In addition for both scenarios, we have some experience with
such things for other reasons and in an earlier era.  If the
infrastructure that supports those alternate roots or shadow
roots isn't as good as the infrastructure which they have come
to expect from the normal root servers, the ISPs and other
operators of major forwarders have tremendous incentives to
refresh at lower frequency than called for in SOA records and to
disable or reinterpret TTL timeouts of data.   For the root
zone, that was pretty much ok around 1995 because data
volatility was very low.  But, in a world in which ICANN is
contemplating thousands of separate delegations from the root
zone, volatility goes up and basing responses on slow-update
alternate roots or non-authoritative and potentially very stale
data... well, you don't cause a lot more IPv6 deployment, but
you certainly damage the quality of DNS-based identifiers.

Again, I saw the smiley so assume that you know the above.  But
the point is that there are similar scenarios, with similar
outcomes, for almost every model for creating a forcing function
for IPv6 based on artificially shutting down IPv4 services.

> Seriously, I do think it is time that the root and TLD's had
> IPv6 only name servers.  I'm not advocating IPv4 be turned off
> on them yet.

If "yet" points to any time prior to the point at which IPv6 is
universally deployed, then the above comments apply to the DNS
and root servers.   

It may be useful to remind ourselves again that getting TCP/IPv4
"universally deployed" in an NCP-based network required a flag
day and a credible threat to disconnect any host that was still
running NCP at the point.  Neither the flag day nor the threat
has plausible analogies in today's Internet.

     john

---

From: Douglas Otis <[email-masked]>
Date: Thu, 10 Jun 2010 19:33:59 -0700

On 6/10/10 3:12 PM, Ned Freed wrote:
>  On 6/10/10 2:48 PM Douglas Otis wrote:
> > Disagree.  HTTP is a bad example, since it allows canonical names
> > to be replaced with a name offered by clients for supporting name
> > based virtual hosts.   In other words, a single port supports
> > thousands of websites. :^)
>  True but irrelevant. The issue isn't support for multiple web sites,
>  it's support for multiple servers. Virtual hosts are fine as long as
>  everything you've got runs under the same web server and on the same
>  hardware. But in many cases things don't work this way. Let's see.
>  I'm running at least seven different pieces of software right now
>  that include a web server component. Now, not all of them provide
>  public services, and for those it doesn't matter that they're not on
>  port 80. But three of them do provide public services.
>
>  Of course redirects and proxies provide a means of getting around
>  these limitations. But now you're talking about a substantial
>  increase in application and configuration complexity. Multiple IPs
>  are a lot simpler and easier to manage.

A Pareto complaint scenario does not require every possible 
configuration be accommodated, when it also accommodates existing 
configurations.  Only a small percentage of customers receive multiple 
IPv4 addresses from their provider.  Of those, only a few run 
incompatible services on different systems.  While those who participate 
within the IETF likely represent an exceptional population, it seems 
unlikely special accommodations for minor portions of a market is 
necessary before progress is possible.  Those who wish to retain their 
current configurations can do so, forgoing IPv6 connectivity.  For them, 
this becomes a question of what overcomes their current equilibrium 
(their PITA factor).  Indirectly this is being answered when large 
providers internally route Internet services using IPv6 when lacking 
adequate IPv4 address space.

 From a security standpoint, direct routing to a device reduces 
complexity and operational issues.  Whether a device is an LP tank 
sensor in the backyard, a power meter on the side of the house, or a 
heat pump in the basement, direct routing offers enhanced functionality 
and security for those who opt-in.  Currently, low-end routers are 
commonly 0wned and are untrustworthy, and often lack adequate logs, 
assuming these logs could be trusted.  Direct routes allow packets to 
arrive unaltered, where only its source is being trusted.

> > The impetus to change occurs after IPv6 becomes an imperative, such
> > as doing business with a region dependent upon IPv6.  After that,
> > complaints related to NATs will fade, and support for IPv4 will be
> > seen as the PITA.  The inflection point for this may move faster
> > than imagined.
>
>  In other words, the way you see this unfolding is that once there's
>  a significant IPv6-connected base somewhere, probably in some
>  emerging market, somebody will view it as  practical to deploy
>  services that can only be reached by IPv6. As more and more of this
>  happens, it will create a need for everyone to have IPv6
>  connectivity, which will then lead to more IPv6-only services, and so
>  on.
>
>  If this is accurate, I think you need to go back and reread John
>  Klensin's recent messages for why this scenario really isn't all that
>  likely to unfold the way you think.

Region might mean a market segment or a geographic area, whether the 
impetus results from a lack of IPv4 address space, a lack of IP 
security, or a lack of functionality.

Do you have a reference to one of John's messages?  Over the years, this 
economic reference has been raised.  Adding complexity to commodity 
devices for a minor portion of a market makes little sense.  Higher-end 
routers offer a solution, but this means considering available 
alternatives when price does not seem justified.  I don't see any 
strategy being proposed to force those not wishing to participate.  For 
years I have had access to multiple static IP addresses, but never used 
more than one, nor would the services you seem to describe meet most 
residential AUPs.

-Doug

---

From: Mark Andrews <[email-masked]>
Date: Fri, 11 Jun 2010 13:04:15 +1000

> least variable) authority.  DNSSec basically has to be turned

The provider only needs access to a dual stack name server.  I don't
know about other vendors but named can run IPv4 only or IPv6 only
and still access zones served only by servers using the the other
flavour of IP and has been able to do so for nearly a decade provided
it has access to a dual stack server somewhere on the internet which
will answer its queries.

> you certainly damage the quality of DNS-based identifiers.

I said adapt, I didn't necessarially mean adapt well or the way
we would want them to adapt.
 
> universally deployed, then the above comments apply to the DNS

I'm thinking 10, 15+ years out when there are lots of IPv6 only
served zones.  Much the same way we no longer worry about MTA's
that don't know about MX records and no longer add A records
to accomodate them.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 11 Jun 2010 10:13:05 +0200

Mark Andrews writes:
> Seriously, I do think it is time that the root and TLD's had IPv6 only 
> name servers.

Why (and do you mean all 6-only or one 6-only)?

Arnt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 11 Jun 2010 07:35:00 -0400

> Turn off the root servers IPv4 address and see how fast people

That is a great idea.

I bet 90% of the net would have stopped using the IANA root servers
within a week. Instead of 13 root server operators we would have maybe
a hundred.

People would certainly adapt, but not in the way you imagine they
would adapt. You see the first law of the Internet is 'you are so not
in charge (for all values of you). The control that IETF and ICANN
impose is illusory.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 11 Jun 2010 08:03:42 -0400

> that don't know about MX records and no longer add A records

Why would there be any IPv6 only served zones?

What John and I have been trying to get across here is that there is
no incentive to create an IPv6 only zone now and never will be in the
future. You present an induction without a base case.

Back in the days when Internet on phones meant WAP, there was a
possibility of them being supported on IPv6. But now the iPhone has
changed the model and the Web on a phone will look just like the rest
of the net and so they have to run IPv4.

That is the big flaw in the IPv6 ready program. It assumes that the
incentive for transition is that IPv6 is a good in itself. It is not,
in fact IPv6 will be slower (more header baggage) than IPv4 and if you
are IPv6 only you will have to go through gateways.

We do seem to be making some progress. I have been banging on about
this problem for six years. When I started NAT was universally
considered to be the problem. People are now seeing the NAT-PT
approach as being a possible framework for a solution rather than
something to be deprecated as 'historic' because they (wrongly)
imagine true Internet is NAT-free.

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 12 Jun 2010 05:09:15 +0900

> capabilities of NAPTR are necessary or even useful for service

Interesting.

The problem of SRV is that it is *NOT* URL friendly that web people
should have no idea on how to use it.

While SRV is designed following the syntax of IP as:

	_Service._Proto.Name TTL Class SRV Priority Weight Port Target

most applications know <Service> and <Proto> by number from
the beginning that there is no room to convert them to ASCII
strings.

The only notable exception, of course, is when URLs are used.
However, as the syntax of Internet URLs is:

	<scheme>://<user>:<password>@<host>:<port>/<url-path>

applications have no information on the ASCII representation of
Proto.

So, SRV should be used as:

	_Scheme.Name TTL Class SRV Priority Weight Proto Port Target

where Weight and Proto are 8 bit quantities to make the RR
format compatible to todays.

Then, if we recommend web people try SRV when "Name" is not
resolved to addresses, they should be happy to use it.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 12 Jun 2010 13:24:46 +0900

Phillip Hallam-Baker wrote:

> The URI syntax you specify is only used for some protocols and most of
> the elements are defaulted. In fact we have got to the point where for
> Web browsing everything is defaulted except for the domain name.

The point was to change the default of 80.

> I think we need to break the idea that a Web service should have a URL
> that starts HTTP.

Try https.

 > Under the covers this would of course expand via SRV to a http URL,

SRV answer gives port numbers and addresses, not a URL.

							Masataka Ohta

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 11 Jun 2010 23:30:03 -0400

Rather, if we are connecting to the Google mapping Web Service we
would type in either

google.com   - if the type of service needed was obvious from the context
ws:google.com:maps   - for the fully qualified version

Under the covers this would of course expand via SRV to a http URL,
probably something of the form

http://services1.google.com/ws/maps/1/0
http://services2.google.com/ws/maps/1/0

Since the SRV record is expanding to a domain name that we presume to
be reserved for hosting of Web services we can take over the
specification of the URI stem in the protocol.

The real advantage of this approach is of course that we then have a
layer that we can later use to lift ourselves off of using HTTP as a
Web Services transport. If the web service offers SSL we can put a
record in the DNS that says 'use SSL for this connection'. If there is
a binary version we can have a hint to say that the binary version is
available.

And within this framework we can slip in a hint to the effect 'works
best with IPv6'

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 12 Jun 2010 11:22:28 -0400

You completely missed the point of my post.

HTTPS is just as bad as HTTP as a URL for a Web Service.

HTTP is a low level protocol, the layering of the Web service on HTTP
or SOAP over HTTP or whatever should be abstracted away in the Web
Service URI. Just like we abstract away the fact we are using TCP/IP.

Removing the clutter allows us to reclaim the URI for use by the Web
Service. At the moment the URI that is submitted to the Web Server has
a mixture of information relevant to the protocol and irrelevant
details that have to do with the administration of the Web Service.

Specifying irrelevant details in the URI makes operation of the
service dependent on them being filled out. Which in turn means that
they are difficult to change. We are creating an unnecessary
management trap for ourselves.

Not specifying those details and allowing them to be filled in using
information from the DNS (SRV records, hints, etc) or defaults means
that THOSE DEFAULTS CAN NOW BE CHANGED WITHOUT IMPACTING SERVICE.

Take your example of using HTTPS. The notion of changing the URI stem
to turn on security is a really bad design. It has left us with a Web
where SSL is the Sunday best you put on for special occasions, not
regular wear. (SSL upgrade could help but is vulnerable to downgrade
attack).

What you really want to have as the 'open socket' API is something like:

OpenWebService (In String dns_name, In String service_prefix, In Enum
minimum_trust,
               Out Socket socket)

Where minimum_trust is  NONE, DomainValidated, OrganizationValidated,
ExtendedValidated)

Just as the standard open call does a number of procedures under the
covers, this API would be doing the SRV failover processing, working
out if upgrade was possible, required, doing path math etc.)

Now APIs are not part of IETF purview. But what is and should be is
creating the conditions that make a highly generic API possible. The
API above only works if the Web Service we want to use conforms to a
particular standard calling mechanism. And that standard should come
from either the IETF or W3C.

The reason that an API is necessary and important is that while it is
easy to implement that in C or C#, it is a heck of a lot of hassle to
do the same in Perl or any of the scripting languages people want to
use - relative to the rest of the code they are writing.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Jun 2010 09:56:28 +1000

In message <ikG3jf9YmyaauWK/[email-masked]>, Arnt Gul
> Why (and do you mean all 6-only or one 6-only)?

Because there are IPv6 only nameservers out there today.  Not
everyone can get a stable IPv4 address to run a nameserver on.  I
can't.  I've got IPv6 only masters which have dual stack slaves.
My IPv6 addresses are stable.  My IPv4 addresses are not.  And
stable IPv4 address will become less available as ISP's introduce
carrier grade NATs (NAT444 or DS-lite).

While TLD's and the root are in positions where they are unlikely
to ever *need* to run IPv6 only, having them run IPv6 only is a
good thing as it show the world that this is a normal and expected
situation.

There is no negative side to running a IPv6 only nameserver.  IPv4
only clients will ignore them.  For IPv6 only and dual stack clients
they are no better or worse than a dual stack server.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Jun 2010 10:10:04 +1000

In message <[email-masked]>, Phil
> Why would there be any IPv6 only served zones?

Because it going to get harder and harder to get stable IPv4
addresses.  ISP's are looking at moving their entire client base
from having unshared public addresses to shared public addresses.

> future. You present an induction without a base case.

Except IPv6 only zones already exist so there must be some incentive to
have them.

> are IPv6 only you will have to go through gateways.

And IPv4 will have multiple header re-writting.  DPI to "fix up" the fact
that headers have been re-written multiple times along with checksum
re-calculations etc.

I actually expect IPv6 to be faster in the end if only marginally.  Most
measurements to day say that IPv4 and IPv6 are roughly the same.

> imagine true Internet is NAT-free.

The more I look at NAT-PT (NAT64/DNS64) the less I like it.  Way
too many kludges especially when there is an alternative, DS-lite,
which doesn't have nearly as many problems that need to be kludged
around.

Mark

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 15 Jun 2010 10:31:16 +0200

Dear all,

I follow this amusing debate - I'm not reacting to this post specifically.

I would like to point out that there are people out there specifying 
communication architectures for new uses of the Internet, e.g. 
Cooperative Systems for communications involving vehicles. The system 
running between all entities composing their network will be living in 
an IPv6-only world. They will only deploy transition mechanisms to keep 
communication going on with other parts of the Internet not running 
IPv6, if that proportion is still significant by the time these new 
systems get deployed (hopefully, they won't have to do so, and for sure 
they won't deploy dual stack).

It seems to me that these new uses are always ignored when one is 
debatting transition from IPv4 to IPv6. In some many cases, it is simply 
transition from something not IP to IPv6. So, there will be IPv6-only 
systems deployed out there (the sad news is that there are also sectors 
transitioning from non IP (e.g. X25) to IPv4 - just because they are not 
aware about IPv6 or are still thinking IPv6 is for the next decade).

Regards,
Thierry.

On 15/06/10 02:10, Mark Andrews wrote:
> In message<[email-masked]>, Phil
> lip Hallam-Baker writes:
>    
>> On Thu, Jun 10, 2010 at 11:04 PM, Mark Andrews<[email-masked]>  wrote:
>>
>>

---

From: Vesna Manojlovic <[email-masked]>
Date: Thu, 17 Jun 2010 14:07:55 +0200

Hi,

> all. If such a product exists I continue to be unaware of it.

recently, RIPE Labs have published the results of a "consumer panel 
testing" of the CPE's (what you refer to as SOHO grade router) :

http://labs.ripe.net/content/ipv6-cpe-survey

Please see the comments, or contribute your results, to the FOrum:
http://labs.ripe.net/node/264/

Also, there is some information on the ARIN's wiki:
http://www.getipv6.info/index.php/Broadband_CPE

Regards,
Vesna Manojlovic
RIPE NCC trainer