Subject: Re: IPv6 addresses really are scarce after all

From: RJ Atkinson <[email-masked]>
Date: Sat, 18 Aug 2007 10:27:36 -0400

I am quite startled by this thread, both in its emotion
and in the apparent oversight of multiple approaches
to the issue of having LOTS of connected user devices
at a house/site/office when an IPv6 /64 prefix has been
provided by one's upstream network provider.

First, giving each end user a /64 means that the user can
have up to 2^^64 devices at their site/home/office.  That
is a whole lot of devices -- more than any one house/site/office
is going to have.  Just as an example, all the IEEE 802
MAC addresses that ever will be issued (now or future)
only would amount to 2^^48 (much smaller than the 2^^64 limit)
since IEEE 802 uses 48-bit MAC addresses -- and a number
of those MAC addresses are reserved for special purposes
(e.g. link multicast MACs, local-scope MACs).

Second, Ethernet bridging is a well understood technology
and it works just fine even with very large numbers of devices.
Some years back I was at a research lab (~2500 people on site)
where virtually everyone had at least one IP connected
computing system (some had more than one).  About 1/4 of that
site was connected via a big yellow Ethernet cable running
classic CSMA/CD Ethernet at 10 Mbps (half-duplex).  We weren't
alone in having very large bridged networks.  A typical house
works fine just with very-low-cost Ethernet switches or hubs
internally and perhaps a very-low-cost IP router between the
house/site/office and the uplink device (e.g. cable modem,
DSL modem, FIOS ONT).  Most wireless access points are not
merely radio repeaters, but also include bridge capability,
so that traffic not needing to go over there air won't.
One nice thing about using bridging is that it doesn't really
care whether the upper layer protocol is IPv4, IPv6, IPX, or
(gasp) CLNP.  "Ethernet just works." (TM)

Third, DHCP is a well understood technology that is deployed
at millions of sites world-wide and generally works quite well.
Those very-low-cost Ethernet routers one can purchase generally
include both DHCP Client (for the uplink interface) and DHCP
Server capabilities (for user devices).  These are normally
configurable.  So one ought to be able to use DHCP to provision
IPv6 addresses (out of that overall block of ~2^^64 IPv6 addresses
mentioned above) using say 16 bits (bits 64-79) for IPv6 subnetting
and the remaining 48 bits for naming IPv6 interfaces.
[NB: While I personally remain a fan of the 8+8 architecture,
so far the IETF has declined to formally adopt that,
so that ought not be an issue for this kind of deployment today.]

Fourth, lots of folks (me included) happen to find it convenient
to use NAT between my site/house/office and my upstream provider.
I'm a bit sceptical of the extravagent security claims sometimes
made for NAT, but I do find it convenient.  Mind, with the other
options above, no one *needs* to use NAT with IPv6 even if their
site/office/house gets a /64 routing prefix.

Now I do think that folks here have overlooked one lurking issue.
So far, few of the very-low-cost Ethernet switch/IP router boxen,
or the very-low-cost wireless bridges/router boxen, or the
very-low-cost security-gateway boxen, support IPv6 at all yet.
One imagines that this is because the vendors of such devices
don't perceive a current large market demand for IPv6 capability.
So the IPv6 advocates might want to go work on making such
very-low-cost boxen available.  If IPv6 really takes off, there
will be money to be made in that market segment.

In turn, the paragraph just above means that most home users
(a price sensitive lot if ever I've seen one) today will be using
some sort of old home-brew BSD/Linux PC-hardware as their
router/bridge.  This means that one has even MORE flexibility
than using the very-low-cost widgets, since shipping BSD/Linux
has a pretty full set of IPv6 capabilities, IPv4 capabilities,
and not a bad set of Ethernet bridging capabilities.  Mind,
such boxes are not easy for novice users to setup and deploy.

So folks, not to worry, there are a number of off-the-shelf
network deployment approaches that are practical and affordable
today to enable significantly sized IPv6 networks to be built
using a single /64, including options that support IPv6 routing
and sub-netting.

:-)

Cheers,

Ran Atkinson
[email-masked]

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

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 21 Aug 2007 03:35:33 +0900 (JST)

caveat: i have not checked the entire thread yet, so it could be a
	duplicate of someone's words.

> have up to 2^^64 devices at their site/home/office.  That

	2^64 interface ID is picked to reduce the possibility (or "probability"
	if you prefer) of address collisions when we use RA.  it does not need
	to be tied with IEEE 802 MAC address - in fact, if i were to use
	bridged ethernet and wireless segment, i prefer to use MD5(hostname)
	just for the ease of migration between wired and wireless.
	(i guess i would like to mention a bit about session layer protocol,
	but that is outside of the point)

> and it works just fine even with very large numbers of devices.

	that's true, but when link MTU is different, it gets very nasty.

> at millions of sites world-wide and generally works quite well.

	ISC dhcp server takes like 5 minutes to reboot when it serves /16
	segment, due to the re-read of /var/run/dhcpd.leases.
	dhcp server is a single point of failure, unless you have a replicated
	lease database among dhcp servers.  if there's implementations or
	practices, i would like to know that.

> to use NAT between my site/house/office and my upstream provider.

	eeeeks.  i wouldn't re-start this religious war, but i just can
	mention that (1) NAT is a single point of failure, and (2) NAT is
	not future-proven so you have to upgrade it forever.

itojun

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 20 Aug 2007 21:25:46 +0200

> and it works just fine even with very large numbers of devices.

That's a meaningless statement. Yes, it works well if you work around  
the limitations. If you create a loop in a bridged network, instant  
fireworks. That's why spanning tree has to be so conservative, which  
is in turn the reason it's not always enabled. With routing on the  
other hand, we call the extra links "redundancy" and it's a good thing.

> classic CSMA/CD Ethernet at 10 Mbps (half-duplex).

Really? When I was in school we had 8 Sun diskless work stations per  
room hooked up to a 10 Mbps switch and when those puppies started to  
swap over the network, you could read a book by the collision light  
and have a chapter finished before your helloworld.c was compiled.

> A typical house
> DSL modem, FIOS ONT).

True. And I agree that switching will be much more important than  
routing in these kinds of networks in the future. Then again, few  
people are worse at predicting the future than engineers. So please  
let's keep our options open.

> at millions of sites world-wide and generally works quite well.

Quick guess: you weren't at IETF-69.

I've seen DHCP fail just as often as pretty much anything else, it's  
not exactly bullet proof.

> So one ought to be able to use DHCP to provision

This requires that all IPv6 nodes do DHCPv6 and there's a DHCPv6  
server. You won't see those two requirements met very often in  
today's IPv6 deployments. However, you WILL see stateless  
autoconfiguration everywhere, and that can only work with /64  
subnets. So you can't re-subnet a subnet in practice. Also, RFC 3513  
says:

    For all unicast addresses, except those that start with binary value
    000, Interface IDs are required to be 64 bits long and to be
    constructed in Modified EUI-64 format.

I have no idea why this sentence is in there, except possibly to make  
sure that stateless autoconfig can work, which may prove challenging  
with a prefix longer than /64.

BTW, I wonder how users will react to address nickel-and-diming by  
ISPs with IPv6 when they can have a /48 with 6to4 tunneling.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 20 Aug 2007 15:12:52 -0700

I am pretty sure the EUI-64 requirement has been dropped. If not I can't see how the real world security practitioners are going to implement it.

The EUI-64 address reveals the hardware manufacturer and model of hardware that I am using. There are no circumstances in which I am going to allow an attacker to obtain that information without putting them to as much effort as I can.

Security through obscurity is bad strategy but good tactics. It is really bad to rely on obscurity in a security architecture but good practice to employ obscurity as an additional control in a layered architecture, particularly when you are dealing with an imperfect security situation that you need to remediate. 

If it is a requirement it is not stated correctly. I do not see a MUST. In fact if I was reviewing the text today I would bork it as stated as not being compliant with the MUST/SHOULD/MAY language. 

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[email-masked]] 

> This requires that all IPv6 nodes do DHCPv6 and there's a 
> DHCPv6 server. You won't see those two requirements met very 
> often in today's IPv6 deployments. However, you WILL see 
> stateless autoconfiguration everywhere, and that can only 
> work with /64 subnets. So you can't re-subnet a subnet in 
> practice. Also, RFC 3513
> says:
> 
> I have no idea why this sentence is in there, except possibly 
> to make sure that stateless autoconfig can work, which may 
> prove challenging with a prefix longer than /64.
> 
> 
> BTW, I wonder how users will react to address 
> nickel-and-diming by ISPs with IPv6 when they can have a /48 
> with 6to4 tunneling.
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 20 Aug 2007 15:12:52 -0700

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Aug 2007 09:14:04 -0400

> to use NAT between my site/house/office and my upstream provider.
do you also find it "convenient" that NAT has effectively thwarted the
deployment of huge numbers of new applications, significantly raised the
cost of deploying others, and harmed the reliability of all applications?

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 Aug 2007 10:54:33 -0400

>>>>> "Keith" == Keith Moore <[email-masked]> writes:

    >> Fourth, lots of folks (me included) happen to find it
    >> convenient to use NAT between my site/house/office and my
    >> upstream provider.
    Keith> do you also find it "convenient" that NAT has effectively
    Keith> thwarted the deployment of huge numbers of new
    Keith> applications, significantly raised the cost of deploying
    Keith> others, and harmed the reliability of all applications?

I find the tradeoffs work in favor of NAT; I expect this to be true
both for V4 and V6.

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 21 Aug 2007 11:22:12 -0400

Hi Phil,

> I am pretty sure the EUI-64 requirement has been dropped. If not I can't see how the real world security practitioners are going to implement it.

Stateless autoconf does not automatically imply EUI-64. There are other 
stateless autoconf methods that do not use bare EUI-64s. See below.

> The EUI-64 address reveals the hardware manufacturer and model of hardware that I am using. There are no circumstances in which I am going to allow an attacker to obtain that information without pu…

You can use a modified 64 bit identifier for privacy. These identifiers 
run a crypto hash over the EUI-64 and keep changing it periodically. 
Thus you can hide your hardware identity both over time and at a 
specific instance of time.

http://tools.ietf.org/html/draft-ietf-ipv6-privacy-addrs-v2-05
(Soon to be RFC4941)

Other mechanisms such as CGA, HBA (more to come ?) also work with 64 bit 
boundaries even if they are not EUI-64 based.

Cheers
Suresh

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 21 Aug 2007 17:29:38 +0200

On 21-aug-2007, at 17:22, Suresh Krishnan wrote:

>> I am pretty sure the EUI-64 requirement has been dropped. If not I  
>> can't see how the real world security practitioners are going to  
>> implement it.

> Stateless autoconf does not automatically imply EUI-64. There are  
> other stateless autoconf methods that do not use bare EUI-64s. See  
> below.

Note that the sense in which the RFC 3513 quote I used refers to  
"modified EUI-64 format" is that the presence of the global/local  
bit. I.e., when this bit is 1 the other 63 bits are globally unique,  
when the bit is 0, no claims of uniqueness are made. This means that  
you can come up with a random, temporary value if you want, possibly  
for reasons of privacy, but then the g/l bit must be set to "local".

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Aug 2007 12:28:05 -0400

> I find the tradeoffs work in favor of NAT; I expect this to be true
but how do you assign a value for those applications that cannot be run,
especially given the diverse needs of the Internet community?

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 21 Aug 2007 09:39:16 -0700

Why is Keith so desperately wedged on one particular means of achieving his objective?

It is entirely possible to make peer to peer applications work well with NAT, it is entirely possible even to make a server application work well with NAT.

We are running out of IPv4 addresses and it is clear that IPv6 is not going to deploy fast enough to allow people to dispense with IPv4 before the exhaustion point is reached. Unless someone happens to have a working time machine handy the only plausible means of getting two billion plus users to attach multiple devices to the IPv4 Internet is for some devices to share an address. That means some form of NAT.

I don't see any reason to expect that my personal Internet needs should require more than an IPv6 /96 and an IPv4 /38. That is 256 ports worth of pooled IPv4 connectivity.

What I want is a little more than a NAT box, I was going to call it an Internet 2 box until Thomas Roessler suggested that the name Internet 2.0 would be more current.

The basic concept of an I2.0 box is that it either plugs into or is a part of the Internet modem device (cable, ADSL, WiMAX, whatever). It has a 'network side' and an 'Internet side'.

The Internet side can run IPv4, IPv6 or dual stack, dual stack support may be a full IPv4 address or a share thereof.

The network side can consist of any combination of IPv6, IPv4 devices in any combination whatsoever. IPv4 service is by default via NAT.

The I2.0 supports some form of port request protocol (UPnP, NAT-PIMP, whatever) and has sufficient smarts to fix up for well known, well used legacy protocols where necessary (FTP, HTTP, SIP). It has a local DNS resolver and makes necessary service assignment information available to applications on the network side via DNS SRV, TXT records in the .local domain.

New application protocols are required to be I2.0 compliant, that means using the DNS as their service discovery mechanism including advertising the IPv4/v6 transition support.

The only administration a user is required to do on an I2.0 box is to tell it which machines are allowed to connect to the network and which applications running on those machines are allowed to access particular Internetwork resources.

Once a rough draft of the I2.0 spec was available manufacturers could advertise their product as being I2.0 compliant provided only that they agree to make an upgrade patch available to support the additional functionality necessary before we reach the IPv4 address crunch.

The killer application for the I2.0 box would be to make videoconferencing work reliably on a shared IPv4 connection. Today this is simply not possible without endless amounts of grief unless you have a technical expert at BOTH ends of the wire. Untold misery is the result of trying to persuade your grandmother to configure her NAT box to forward the correct IP ports, for added fun try doing this where said grandmother is using VOIP off the same box.

> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Tuesday, August 21, 2007 10:55 AM
> To: Keith Moore
> Cc: RJ Atkinson; [email-masked]
> Subject: Re: IPv6 addresses really are scarce after all
> 
> I find the tradeoffs work in favor of NAT; I expect this to 
> be true both for V4 and V6.
>

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Aug 2007 12:46:27 -0400

> Why is Keith so desperately wedged on one particular means of achieving his objective?
because it's by far the simplest and most reliable means available.
> It is entirely possible to make peer to peer applications work well with NAT, it is entirely possible even to make a server application work well with NAT.
it is possible.  it is also much more complex to make things work that
way, much more expensive, harder to make such applicaitons scalable, and
much harder to diagnose problems when they crop up.
> We are running out of IPv4 addresses and it is clear that IPv6 is not going to deploy fast enough to allow people to dispense with IPv4 before the exhaustion point is reached. Unless someone happen…
NAT is a given in IPv4.  no argument there.
> I don't see any reason to expect that my personal Internet needs should require more than an IPv6 /96 and an IPv4 /38. That is 256 ports worth of pooled IPv4 connectivity.
there you go trying to impose your personal needs on the entire Internet
again.
> New application protocols are required to be I2.0 compliant, that means using the DNS as their service discovery mechanism including advertising the IPv4/v6 transition support.
and I see you're also trying to saddle the entire Internet with 1970s
peer discovery technology.

Keith

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 21 Aug 2007 18:51:51 +0200

On 21-aug-2007, at 18:39, Hallam-Baker, Phillip wrote:

> It is entirely possible to make peer to peer applications work well  
> with NAT, it is entirely possible even to make a server application  
> work well with NAT.

It is entirely possible to make it so that you can breathe under  
water. When the need arises, we build the necessary installations.  
That's not to say that collectively starting to live under water is a  
good idea, even if it solves the sea level rising problem.

Running NAT is like quoting the complete original message of the  
previous speaker. If some people do it but others clean up the mess,  
it doesn't seem that harmful. If everyone starts doing it, things get  
very messy very fast.

Please use NAT if that's what you want to do. Even use NAT and IPv6  
together if you think that's a good idea. (I tried that just to see  
what would happen; it isn't.) But don't think you can sell the  
virtues of NAT to the IETF. "It wastes your time and annoys the pig"  
and all that.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 22 Aug 2007 09:17:53 +1000

> I find the tradeoffs work in favor of NAT; I expect this to be true

	Try tftp booting two devices from behind a NAT w/o a tftp
	ALG.

	Yes this is a obscure case but is is a perfect example of
	why NAT is evil.  Things that just should work fail and
	there is no end user fix.

	With a plain firewall you can add rules to let the reply
	traffic through.

	With a NAT you have to choose which device gets to boot as
	you can't port forward both sets of replies.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 22 Aug 2007 11:28:03 +0200

On 22-aug-2007, at 4:39, RJ Atkinson wrote:

> In one's home network, which was and is the subject of this thread,
> one ought not worry about backhoes taking out the cabling in the
> attic.  Since the uplink to the ISP would have a router in any
> event, the part that might need to be redundant (i.e. the uplink)
> can easily be redundant. :-)

Then again, mistakes are made even easier than in a more professional  
setting. I have even created a loop between two ports in a switch and  
two ports on a wireless base station myself accidentally because I  
forgot the base station was in bridge mode and not NATing between its  
two ports.

>> Really? When I was in school we had 8 Sun diskless work stations  
>> per room hooked up to a 10 Mbps switch and when those puppies  
>> started to swap over the network, you could read a book by the  
>> collision light and have a chapter finished before your  
>> helloworld.c was compiled.

(hub, not switch)

> Absolutely yes.

> That school's network/workstations must have been misconfigured.
> We had easily over 1000 UNIX workstations on the same big yellow
> Ethernet back in the day, without the kinds of issues you describe.

It wasn't misconfigured. This was simply before the days of  
affordable fast ethernet or ethernet switches, so it was a big 10  
Mbps ethernet which simply wasn't fast enough to accommodate all the  
NFS traffic for the diskless work stations. If the systems had had  
local storage and the network traffic had been telnet and mail, there  
wouldn't have been any trouble.

> One deployment having issues is VERY different from
> most deployments having issues.

I'm not saying most deployments have problems. I'm saying DHCP isn't  
immune to problems. And when you have a problem with your DHCP, your  
network is pretty much dead in the water.

>> today's IPv6 deployments.

> Most IPv6 workstations/laptops support DHCPv6 client at least.

Untrue. Maybe the latest BSD/Linux distros come with one, but that  
would be a recent development. Windows XP and MacOS X don't do DHCPv6.

> DHCPv6-capable servers are not rare within the set of IPv6-capable
> routers/systems.

Cisco routers do DHCPv6 but no address assignment. I haven't seen any  
other production-quality DHCPv6 implementations. (But the last time I  
looked was 2 years ago.)

---

From: Jari Arkko <[email-masked]>
Date: Wed, 22 Aug 2007 13:26:11 +0300

I'm not sure we need to debate the subnet vs. bridging
question. Of course bridging will go a long way; yet I
don't think anyone on this thread wants to claim that
we should limit home networks to it.

The crux of the issue is the unpredictability of what
will happen with technology, a particular type of a
site, and a specific user. We give an allocation to
someone right now, what will happen in five years?
How big has his network grown, and what technology
does it use? If we guessed wrong and gave the user
too small prefix, there will be pain -- new requests
for space to the ISP, restricted growth of the user's
network, renumbering, multiple routing entries
instead of one, etc.

If we guess wrong the other way and give the user
too much, this either does not matter at all, or we
waste addresses, depending on whether the
allocations cause actual address shortage. It is
obvious that allocations need to be tailored
to the need -- I don't want DSL users assigned
as many addresses as providers or multi-national
corporations get. But the question is at what
granularity are we doing this, and at what point
do we stop caring about the details? Personally,
I think the 48 bit boundary works pretty well and I
do not see a real-life reason to worry about address
shortage. Having said that, something slightly more
fine grained would work too, e.g., 48 or 56, or
what Iljitsch proposed. Tuning the policy every
few bits seems unnecessary, IMHO.

A couple of relevant IETF links:

  http://tools.ietf.org/html/rfc3177
  http://tools.ietf.org/id/draft-narten-ipv6-3177bis-48boundary-02.txt
(currently in state Dead)

Finally, I hope this thread does not stay only within the
IETF list and that some of you actually voice your opinions
in the ARIN process. (But as Tony noted, ARIN just makes
policy with respect to how it hands out addresses -- its
the actual providers that sell the service to customers.
Neither the IETF or ARIN have direct control of this,
though of course we like to encourage ease of address
allocation.)

Jari

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 23 Aug 2007 11:23:53 -0700

If we can meet the needs of 80% of Internet users with some form of shared access there will be more addresses left for the 20% with greater needs.

I suspect that the actual percentages are more like 95% and 5%.

My Internet use is certainly not typical, it is considerably more intensive than the median user.

And as for the claim that I would saddle the Internet with a 1970s technology, I don't think that DNS counts. For a start the SRV record only appeared in the late 90s. It is much easier to rant against something when you don't bother to find out what it is.

Still I note that Kieth is no longer opposing IPv4 NAT which is something. 

> From: Keith Moore [mailto:[email-masked]] 
> Sent: Tuesday, August 21, 2007 12:46 PM
> To: Hallam-Baker, Phillip
> Cc: Sam Hartman; RJ Atkinson; [email-masked]
> Subject: Re: The Internet 2.0 box Was: IPv6 addresses really 
> are scarce after all
> 
> > It is entirely possible to make peer to peer applications 
> work well with NAT, it is entirely possible even to make a 
> server application work well with NAT.
> >   
> it is possible.  it is also much more complex to make things 
> work that way, much more expensive, harder to make such 
> applicaitons scalable, and much harder to diagnose problems 
> when they crop up.
> > We are running out of IPv4 addresses and it is clear that 
> IPv6 is not going to deploy fast enough to allow people to 
> dispense with IPv4 before the exhaustion point is reached. 
> Unless someone happens to have a working time machine handy 
> the only plausible means of getting two billion plus users to 
> attach multiple devices to the IPv4 Internet is for some 
> devices to share an address. That means some form of NAT.
> >   
> > I don't see any reason to expect that my personal Internet 
> needs should require more than an IPv6 /96 and an IPv4 /38. 
> That is 256 ports worth of pooled IPv4 connectivity.
> >   
> there you go trying to impose your personal needs on the 
> entire Internet again.
> > New application protocols are required to be I2.0 
> compliant, that means using the DNS as their service 
> discovery mechanism including advertising the IPv4/v6 
> transition support.
> >   
> and I see you're also trying to saddle the entire Internet 
> with 1970s peer discovery technology.
> 
> Keith
> 
>

---

From: Keith Moore <[email-masked]>
Date: Thu, 23 Aug 2007 15:40:49 -0400

> If we can meet the needs of 80% of Internet users with some form of shared access there will be more addresses left for the 20% with greater needs.
with 2**128 potential addresses, this is not only unnecessary, it's
harmful.  there's far greater benefit to be had by uniformity in address
allocation, globally unique addresses, and consistent use of addresses
end-to-end.
> And as for the claim that I would saddle the Internet with a 1970s technology, I don't think that DNS counts. For a start the SRV record only appeared in the late 90s. It is much easier to rant aga…
DNS is the Achilles heel of the Internet.  it's way too unreliable, too
hard to configure correctly, too often out-of-sync with the real world. 
it's not extensible enough.  practical DNS security might finally be
here  - I'm trying to keep an open mind about that - but I'll be a
believer when I see it widely deployed.  and in practice there's a huge
amount of DNS abuse - e.g. multifaced servers that return inconsistent
results depending on who is asking.  basically DNS is not the sort of
thing you want to saddle every application in the Internet with, and
there are significant incentives for applications to take whatever DNS
says with a grain of salt.
> Still I note that Kieth is no longer opposing IPv4 NAT which is something.
well, I would hope we've learned our (rather painful) lesson.  but it
seems that some of us have not.

but the only reason I don't oppose IPv4 NAT is that I recognize that
IPv4 is a dinosaur.  it's too late to fix it.

Keith

---

From: Sam Hartman <[email-masked]>
Date: Thu, 23 Aug 2007 16:12:17 -0400

Keith> Hallam-Baker, Phillip wrote:
    >> If we can meet the needs of 80% of Internet users with some
    >> form of shared access there will be more addresses left for the
    >> 20% with greater needs.
    >> 
    Keith> with 2**128 potential addresses, this is not only
    Keith> unnecessary, it's harmful.  there's far greater benefit to
    Keith> be had by uniformity in address allocation, globally unique
    Keith> addresses, and consistent use of addresses end-to-end.

I'll take ease in renumbering over application transparency for any
large network.

---

From: "Larson, Matt" <[email-masked]>
Date: Thu, 23 Aug 2007 16:54:41 -0400

On Thu, 23 Aug 2007, Keith Moore wrote:
> basically DNS is not the sort of
> thing you want to saddle every application in the Internet with,
> [...]

It would seem that you are 20+ years too late.  Just what color are
the Frogstar fighters in your universe, anyway? [1]

Matt

[1] http://en.wikipedia.org/wiki/Frogstar#Frogstar and
http://en.wikipedia.org/wiki/Minor_characters_from_The_Hitchhiker's_Guide_to_the_Galaxy#Roosta

---

From: Stephen Kent <[email-masked]>
Date: Thu, 23 Aug 2007 15:03:33 -0400

At 11:23 AM -0700 8/23/07, Hallam-Baker, Phillip wrote:
>If we can meet the needs of 80% of Internet users with some form of 
>shared access there will be more addresses left for the 20% with 
>greater needs.
>
>And as for the claim that I would saddle the Internet with a 1970s 
>technology, I don't think that DNS counts. For a start the SRV 
>record only appeared in the late 90s. It is much easier to rant 
>against something when you don't bother to find out what it is.

The DNS is a 1980's technology. We used hosts.txt prior to that.

Steve

---

From: Dave Cridland <[email-masked]>
Date: Thu, 23 Aug 2007 22:25:01 +0100

> I'll take ease in renumbering over application transparency for any

I find this confusing as a concern - how often do you renumber? 
Compare this to how often you run applications which benefit from 
transparency. I'm pretty sure I've run FTP, for example, at least 
twice since I last renumbered. I've even run VOIP - another prime 
consumer of network transparency.

I agree that renumbering isn't a trivial exercise, but if your 
external address changes in NAT, it's just as painful (if not 
slightly more so) for externally facing services, surely? And with 
IPv6, doesn't renumbering get easier? (I thought it did, when I 
renumbered mine, and I had to do so at very short notice).

I'm quite possibly being naïve, or stupid, or all three, but I don't 
follow why renumbering is a sufficiently major concern that 
applications must suffer.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: David Conrad <[email-masked]>
Date: Thu, 23 Aug 2007 17:48:00 -0700

> I find this confusing as a concern - how often do you renumber?

How often do you want to change service providers?

Regards,
-drc

---

From: Keith Moore <[email-masked]>
Date: Thu, 23 Aug 2007 20:54:46 -0400

> I'll take ease in renumbering over application transparency for any
Fair point.  Though I actually think what we really need is a layer of
indirection at the BGP level so that sites can have stable addresses
without having to NAT.   

I don't try to keep up with BGP but I thought at one time that I saw a
proposal for an extension to BGP to do something very similar to this.

---

From: Keith Moore <[email-masked]>
Date: Thu, 23 Aug 2007 21:09:41 -0400

> The DNS is a 1980's technology. We used hosts.txt prior to that.
yeah, that was a typo.  (and I do remember using hosts.txt)

though somehow, 1980s technology doesn't sound a lot better.

---

From: Keith Moore <[email-masked]>
Date: Thu, 23 Aug 2007 21:12:04 -0400

Larson, Matt wrote:
> the Frogstar fighters in your universe, anyway? 
I have never had the impression that DNS was a mandatory layer in the
protocol stack.  Applications can and do exchange IP addresses, for very
good reasons.  DNS is just another application among many that do that.

---

From: Dave Cridland <[email-masked]>
Date: Fri, 24 Aug 2007 09:32:22 +0100

> How often do you want to change service providers?

Well, I have a pretty good one, so not often. But even if I did, I'd 
still have three further answers:

1) If my network was sufficiently huge and mission-critical, I'd have 
multiple upstreams and an AS.

2) If my network runs public services, then renumbering is still 
painful, since my externally facing address[es] - those that I run 
the service from - are changed.

3) I change network provider less often than I talk to my mother. 
(Using Jingle/XMPP, a protocol which doesn't require, but certainly 
benefits from, network transparency and direct addressing).

I'm honestly struggling to see what the issue is here. I certainly 
agree that renumering is a pain, but I don't follow why renumbering 
is so significantly painful that it's worth breaking the network for. 
I'm not saying it isn't, I just can't see how it is, and would 
appreciate some enlightenment.

Dave.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 24 Aug 2007 03:08:34 -0700

Isaiah Berlin, the founder of my Oxford college wrote "In the field of political philosophy, novelty is not a virtue." He wasn't that keen on novelty in other fields either, criticising academics for prefering novelty for truth.

I am an engineer, not an academic.

I try to learn from past efforts - both negative and positive. You on the other hand demand that we consider the 1983 design of the Internet as sacrosanct, except of course when you are sneering at people for proposing '1980s technology'.

> Sent: Thursday, August 23, 2007 9:10 PM
> To: Stephen Kent
> Cc: Hallam-Baker, Phillip; RJ Atkinson; Sam Hartman; [email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Fri, 24 Aug 2007 09:20:09 -0400

Keith Moore <[email-masked]> writes:

> it's not extensible enough.

DNS is surely the worst global naming system ever invented, except for
all the others that have been tried.

I'm sure that if we were to go back to a clean slate, and reinvent a
new system, and it had to have such key properties as scalability,
global-scope, etc., etc., it would look astonishingly like the DNS we
have today.

How many times have people tried to develop a faster, cheaper, more
reliable (UDP-based) transport protocol to replace TCP? And the resuls
of those efforts are where?

Railing against the shortcomings of the current DNS (or any current
technology, for that matter) does little to get us to a better system.
If you know of a better approach, what are you doing to make it a
reality?

Thomas

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Aug 2007 10:37:44 -0400

> I try to learn from past efforts - both negative and positive. You on the other hand demand that we consider the 1983 design of the Internet as sacrosanct, except of course when you are sneering at…
Okay, fair enough.  Actually the Internet design is several years older
than 1983, and I'll note that I've also recently said that IPv4 is a
dinosaur, so it's not as if I regard it as sacrosanct.  And we have a
replacement for the IPv4 protocol that is based on experience with that
protocol, and which tries to improve upon at least its most obvious
deficiencies while preserving its best design points.  The parts of IPv4
that I defend are those that were found to work well - like global
addressing, and a clean separation of function between the packet
routing layer and the layer that guarantees  reliable message delivery. 
One part of IPv4 that I believe really needs to be improved on is the
failure of IPv4 (due to a fixed-length address and a shortage of address
bits) to really implement the catenet model that lets any network be
connected to any point to the existing Internet.  Another part is the
poor support for autoconfiguration, especially of small networks. 

As for NAT, we have plenty of experience that shows that NAT was, at
least architecturally, a bad idea.  NAT can be defended as a stopgap
measure, and it can be argued that NAT points out architectural
deficiencies in IPv4.  But NAT doesn't solve those problems, but rather
moves them and makes things worse overall.  It also creates a tussle
between the interests of application implementors and the interests of
enterprise network operators where one did not exist before.

DNS has been stretched far beyond its original design goals, and in the
future it seems likely to be stretched even more - there are no shortage
of things we'd like to do with this distributed database.  Even with
respect to its original design goals several deficiencies are now
obvious.  An orderly and carefully-engineered replacement of DNS is
common sense.  What makes no sense is the notion that we have to make
DNS even more critical path than it was intended to be.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Aug 2007 10:49:08 -0400

> If you know of a better approach, what are you doing to make it a
The purpose of my argument was to dispel the notion that DNS should be
critical path for every application so that it can then be used as a way
to make NAT work better.  In general, I don't believe we should make
anything in the Internet mandatory with the possible exception of IP -
and we've found that we need to replace even IP (painful though this
is).  We should keep the Internet architecture flexible enough that
there's always the potential to replace layers above or below IP. 
(another limitation of NAT, though NAT's not the only thing that harms
this.)

I believe I understand how to replace DNS with a better protocol while
preserving the existing hierarchy and RRsets and DNSSEC, and allowing
graceful transition from the old to the new.  However, I'm not sure that
I have enough understanding of DNS's failings to engineer something that
addresses all or most of them - I just know about the ones I've run
into.  But I'd like to hear from other people who are interested in
replacing DNS, maybe we could collaborate on a proposal that shows how
DNS could be improved and how replacement of DNS is feasible.

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 24 Aug 2007 15:56:20 +0100

Keith Moore wrote:
[..]
> DNS could be improved and how replacement of DNS is feasible.

Might I suggest that you first start doing what most sensible people
have been doing over the long long years of human existence:

 - define your problem
 - define what you want to solve
 - define for what you want to solve it

And then after that is all done, realize that the problem you have is
very difficult.

The IETF has a simple process for all of this: write a draft.
And the alternative process is: build running code.

But afaik you already know about this. Bickering about all this is fun
of course, but it doesn't help coming to a solution, especially as the
solution doesn't have a defined problem set and what it is supposed to
solve.

Greets,
 Jeroen

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Aug 2007 11:12:41 -0400

> Bickering about all this is fun
of course.  but the purpose was not to bicker, but rather to do some
damage control - to try to discourage people from making DNS critical
path so that they could then damage the net even further by making NAT
critical path.

it shouldn't be necessary to design or implement a new protocol to
dispel bad ideas.

---

From: David Conrad <[email-masked]>
Date: Fri, 24 Aug 2007 08:28:10 -0700

Dave,

On Aug 24, 2007, at 1:32 AM, Dave Cridland wrote:
> is so significantly painful that it's worth breaking the network  
> for. I'm not saying it isn't, I just can't see how it is, and would  

If you obtain address space from a service provider and you decide to  
change providers, you have (in most cases) two options: renumber or  
deploy NAT. It is a simple cost/benefit tradeoff, with the costs  
impacting software and protocol developers not really a  
consideration.  From the perspective of the network administrator,  
which is easier?  Going through every configuration file, network  
management program, firewall, router, etc. throughout their entire  
infrastructure and changing every reference to IP addresses or  
deploying a new box into the network infrastructure (and I'm not  
going to go into whether or not that box is deemed to have provide  
additional security)?  Obviously, if you obtain provider independent  
address space, you don't need to renumber.  Unfortunately, this  
doesn't scale.

Regards,
-drc

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 24 Aug 2007 17:46:27 +0200

On 24-aug-2007, at 17:28, David Conrad wrote:

> If you obtain address space from a service provider and you decide  
> to change providers, you have (in most cases) two options: renumber  
> or deploy NAT.

Nonsense.

Assuming you're not going to take the address space with you (which  
is not a given, btw), there's no way to avoid renumbering. If you use  
NAT with RFC 1918 addresses internally the renumbering is limited to  
stuff outside your internal network. And this is the hard part  
anyway. But if you don't use NAT adopting NAT means you'll have to  
renumber internally as well because someone else will be using your  
old addresses in the future so you can't keep using them internally.

I think it's time that the [email-masked] filters flag all messages  
with the word "NAT" in it as spam. NAT discussions are always  
fruitless: we're not going to get rid of it in the IPv4 world and  
using it even more than today won't fix any of our problems, so NAT  
is orthogonal to any high-level IETF discussion.

---

From: <[email-masked]>
Date: Fri, 24 Aug 2007 17:18:01 +0100

> The IETF has a simple process for all of this: write a draft.

Not true. 

The IETF also runs a large number of mailing lists for discussion of
things both general and specific. It is not necessary to start work by
writing a draft. One can also start work by discussing the problem area
on one or more of the mailing lists, especially when one believes that
the work can best be done by a team, not by one lone author of an ID.

And that is what Keith has done, stated the outlines of the problem
area, a way forward, and asked if anyone wants to help him work on the
problem.

No reason to attack him like you did and I specifically want to address
this because mailing lists have a much larger audience than their
participants. If such attacks are not answered it creates barriers for
new blood to enter into the IETF process. Please don't do this.

--Michael Dillon

---

From: "Roger Jørgensen" <[email-masked]>
Date: Fri, 24 Aug 2007 18:36:51 +0200

On 8/24/07, [email-masked] <[email-masked]> wrote:
<snip>
> new blood to enter into the IETF process. Please don't do this.

A wild guess from my side, I think quite some fresh blood are scared
of by the path they have to follow to get through with their ideas or
thoughts.

Not so much the way their questions are answered but it certainly
don´t help to be bitched at either:)

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: David Conrad <[email-masked]>
Date: Fri, 24 Aug 2007 09:44:27 -0700

On Aug 24, 2007, at 8:46 AM, Iljitsch van Beijnum wrote:
>> to change providers, you have (in most cases) two options:  
>> renumber or deploy NAT.
>
> Nonsense.

Sigh.  I forgot to be pedantic and use the IETF-mandated terminology.

If you obtain address space from a service provider and you decide to  
change providers, you have (in most cases) two options: renumber your  
entire infrastructure or deploy *EVIL* NAT and only renumber the  
external infrastructure.

> fruitless:

Thanks for playing your part.

Regards,
-drc

---

From: Michael Thomas <[email-masked]>
Date: Fri, 24 Aug 2007 09:45:47 -0700

> don´t help to be bitched at either:)
IMO, there is almost no point days of trying to engineer a protocol in the
IETF that doesn't have some real world grounding ahead of time. At the
very least, it shows that somebody(s) have made more of a commitment
than just getting another RFC number on their resume. This also neatly
routes around the damage of being shouted down while an idea is in its
infancy, and spares the ridicule if it really was a bond-headed idea since
you can abandon it instead of taking it to IETF. No such escape valve exists
for ungrounded/untested protocols, unfortunately.

I wonder what percentage of RFC's are stillborn these days.

       Mike

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 24 Aug 2007 11:46:06 -0500

> I think it's time that the [email-masked] filters flag all messages  with 
> the word "NAT" in it as spam. NAT discussions are always  fruitless: we're 
> not going to get rid of it in the IPv4 world and  using it even more than 
> today won't fix any of our problems, so NAT  is orthogonal to any 
> high-level IETF discussion.

I can't decide if Dan Wing would think that flagging all IETF mailing list 
discussion of NAT as spam would be a good thing, or a bad thing ...

... perhaps we should finish the BEHAVE specifications first? Otherwise, the 
Last Call discussion may be a trifle strange.

:-)

Spencer, who is not unsympathetic to the proposal, only to the timing ...

---

From: "Roger Jørgensen" <[email-masked]>
Date: Fri, 24 Aug 2007 18:51:13 +0200

On 8/24/07, David Conrad <[email-masked]> wrote:
<snip>
> address space, you don't need to renumber.  Unfortunately, this

sound to me that what we need is a new way to
- configure hosts
- configure routers
- configure ACL on routers/firewall/wherever
- services (http, mail ++++)
- dns (a bit special, more about it further down)

where it is possible to do the change ONE place and get all other
fields like the same changed at the same place in all of the above
place and other I have forgotten... and at the same place have the
changes be done transparent or with as short outages as possible,
less than 1minut I would say. In other word.

We need to get totaly ride of the manual configuration that has to
be done when changing IP addresses, changing domain names
etc. NA/RA build into IPv6 has some of this but it just make it possible
to configure IP on the host...

DNS is one place this could be done, but DNS isn't trustworthy enough
yet, and we also have the NAT/RFC1918 ip addresses that make it
harder.
But without such a automatic system we are forever bound to IP
addresses, or hostnames wherever we go.

-- 

Roger Jorgensen           |

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 24 Aug 2007 19:03:29 +0200

On 24-aug-2007, at 18:44, David Conrad wrote:

>>> If you obtain address space from a service provider and you  
>>> decide to change providers, you have (in most cases) two options:  
>>> renumber or deploy NAT.

> your entire infrastructure or deploy *EVIL* NAT and only renumber  
> the external infrastructure.

Regardless of the theatrics, this statement is still incorrect. As I  
said in my previous message, you can't keep the old addresses  
internally either so all of this buys you nothing.

NAT is only useful if you feel that renumbering individual machines  
is more cumbersome than running NAT and renumbering address  
translation mappings (as well as any external stuff in both cases, of  
course). Hosts aren't that hard to renumber with DHCP so basically  
this only helps you avoid renumbering your routers and other non-host  
devices with IP configurations on them.

---

From: David Conrad <[email-masked]>
Date: Fri, 24 Aug 2007 10:18:11 -0700

Iljitsch,

On Aug 24, 2007, at 10:03 AM, Iljitsch van Beijnum wrote:
> Regardless of the theatrics, this statement is still incorrect. As  
> I said in my previous message, you can't keep the old addresses  

I suspect the number of people who NAT into something other than RFC  
1918 space is infinitesimally small and had assumed it was not  
necessary to explain the use of RFC 1918 space.

Your contributions to this thread have undoubtedly added great clarity.

Regards,
-drc

---

From: Terry Gray <[email-masked]>
Date: Fri, 24 Aug 2007 10:36:33 -0700 (Pacific Daylight Time)

There seems to be consensus that trying to stop NAT in the v4 world is 
futile.  Good.  So then we ask: "what will keep it from happening in 
the v6 world?"

I postulate the following as one necessary, and perhaps sufficient, 
condition:

IN ORDER TO AVOID v6 NAT: Network administrators of any home or 
enterprise network need to have, at essentially zero cost, "ownership" 
or control over SOME NUMBER of bits of the v6 address space, 
sufficient to uniquely address each host in their network, and such 
that a change in ISP or upstream topology (the higher-order address 
bits) does not require reconfiguration of end-systems OR OF ANY 
TRAFFIC-DISRUPTION-APPLIANCES THAT LIVE WITHIN THAT NETWORK... many of 
which implement policy restrictions based on host IP addresses.

This is a refinement of my earlier comment that v6 addresses must be 
both free and provider-independent in order to avoid pervasive v6 NAT.

I think that those who believe v6 DHCP and auto-conf are sufficient to 
avoid the PI or local-autonomy requirement are deluding themselves, 
but one cannot prove such propositions until it is too late to prevent 
the undesired outcome.

Counter-arguments?

What are the prospects that the condition above could be met at this 
late date?

-teg

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Aug 2007 14:43:27 -0400

nice idea, but I'm fairly convinced that it's impractical.  there are
just too many interfaces, many of them nonstandard and application
specific, that need to know about IP addresses.

maybe we could come up with a 90% solution, but that 10% is still a bear.

I'm back to thinking that we have to find some way to provide PI space
to everyone.  and I'm not convinced that it doesn't scale to give
customers PI space and have PI addresses in IP packets, even though I'm
fairly convinced that trying to do routing in terms of customer PI space
doesn't scale.

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Aug 2007 14:49:00 -0400

> which implement policy restrictions based on host IP addresses.
pretty much agree, though I'm also fairly convinced that that SOME
NUMBER == 128.

in particular, I don't believe it's reasonable to expect applications to
be aware of network topology or to use different kinds of addresses
depending on the topology within which they will be used.  pairwise
address selection (selecting destination address based on source address
or vice versa) is not sufficient.

Keith

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Sat, 25 Aug 2007 03:56:38 +0900 (JST)

> but one cannot prove such propositions until it is too late to prevent 

	from realworld experience in providing IPv6 services at an ISP,
	and as a customer of that service:

	/48 PA assignments to the customer is sufficient.
	for roaming clients (like travelling laptops with PPP) there's a
	different requirement.

	anyone who would like to comment on this topic should better have
	real experience in assigning prefixes to the customers :-P

itojun
# ipv6samurais.com: saving the world with code and sword

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Aug 2007 16:26:16 -0400

> 	for roaming clients (like travelling laptops with PPP) there's a
IMHO even a traveling laptop with PPP needs to be able to subnet.   
I've lost count of the number of times I've needed to do this in IPv4
but been stuck with a single /32.  I have also lost count of the number
of times I've used a laptop as a router in the days when I had a /28
routed to me.  Built in NAT capability for IPv4 that allows a single PPP
connection to be shared over wireless seems fairly common these days. 
We need the equivalent capability in IPv6, just without NAT.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Sat, 25 Aug 2007 05:31:54 +0900 (JST)

> We need the equivalent capability in IPv6, just without NAT.

	agreed, like your laptop providing connectivity for your music player
	(like iPod), SIP-ready phone (like Symbian phones) and such.
	the internet infrastructure should keep options open for the other
	industry player to play with.

itojun

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Aug 2007 16:44:56 -0400

> 	(like iPod), SIP-ready phone (like Symbian phones) and such.
or for that matter, other laptops and their users' iPods, phones, etc.

---

From: "Roger Jørgensen" <[email-masked]>
Date: Sat, 25 Aug 2007 00:03:42 +0200

> fairly convinced that trying to do routing in terms of customer PI space

ULA-C/G for everone? :)

<snip>

-- 

Roger Jorgensen           |

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 28 Aug 2007 13:08:18 -0700

You are not comparing like with like.
 
Early Sun's had an ethernet driver that would retry without waiting after a collision. This meant that if you put a single sun workstation on a network of VAXen the sun would appear to be really fast and the Vaxen slow. 
 
If you had a lot of sun workstations together, particularly diskless ones the result was pretty terrible.

I don't see what the relevance is however, the diskless workstations that caused the real issues were paging over the ethernet. I can't see how you would end up in that situation today, RAM is cheap, implementing virtual memory is going to be unnecessarily complex. It isn't a set of compromises you are likely to find these days.
 
Of course there are going to be embedded devices that boot from a network image.

________________________________

From: RJ Atkinson [mailto:[email-masked]]
Sent: Tue 21/08/2007 10:39 PM
To: Iljitsch van Beijnum
Cc: [email-masked]
Subject: Re: IPv6 addresses really are scarce after all

On  20 Aug 2007, at 15:25, Iljitsch van Beijnum wrote:
> That's a meaningless statement. Yes, it works well if you work 
> around the limitations. If you create a loop in a bridged network, 
> instant fireworks. That's why spanning tree has to be so 
> conservative, which is in turn the reason it's not always enabled. 
> With routing on the other hand, we call the extra links 
> "redundancy" and it's a good thing.

Absolutely yes.

Yours,

Ran
[email-masked]