IPv6 Confusion

Carl_Rosevear · February 17, 2009, 4:59pm

So, I understand the main concepts behind IPv6. Most of my peers understand. We all have a detailed understanding of most things IPv4. I have Googled and read RFCs about IPv6 for HOURS. That said, to quickly try to minimize people thinking I am an idiot who asks before he reads, I need some answers. First of all, several of my friends who feel they are rather authoritative on the subject of things network-related have given me conflicting answers. So what's the question? ...

How does IPv6 addressing work?

I know it's been hashed and rehashed but several orgs I am associated with are about to ask for their allocations from ARIN and we are all realizing we don't really know how the network / subnet structure trickles down from the edge to the host. We really don't have a firm grasp of all of this as there seems to be multiple options regarding how many addresses should be assigned to a host, if the MAC address should be included in the address or if that is just for auto-configuration purposes or what the heck the deal is. There are a lot of clear statements out there and a lot that are clear as mud. Unfortunately, even when trying to analyze which RFC superseded another. Can I just subnet it all like IPv4 but with room to grow or is each host really going to need its own /84 or something? I can't see why hosts would need any more addresses than today but maybe I'm missing something because a lot of addressing models sure allow for a huge number of unique addresses per host.

My buddy and I are about to go to Barnes and Noble, not having and luck with standard internet media but then we realized... how will we know if any of that is really what we are looking for either?

From what I can tell, this may still be a question of great debate. Everyone seems to act like they know exactly what's going on but behind closed doors admits that they don't really know x, y, or z. I realize this is typical of my industry and even myself from time to time. J

But so I am truly reaching out here. What is the deal with IPv6 addressing and subneting? Where is the official guide to this new galaxy? I will be sure to pass this information on to my equally less clueful peers to the benefit of all of us that are making this transition.

There are people here at my company that seem to get it but can't seem to explain it clearly to me. To me, its basically just larger addressing space with some new logical boundaries.... But there are so many discussions of potential addressing methods that I am confused. I know from my lab setups that I can "make it work" but I'd like to "do it right". J

I've been doing this for over 10 years now... IPv4 is native to me. If you can point me in the direction of some good, authoritative information or even say "Dood, go get IPv6 for dummies", that's fine I just need to know where to find some good information.

Can someone say "well, you know how it would be nice to have like 100 different addresses on hosts to differentiate services and blah blah.... Well now that's what you account for and so then you know how a /24 almost always ends up being tight in IPv4? Right, so think of your basic bit boundaries that you adhere to as /?? And /??? In IPv6." Or "Throw all that old thought out the window. Now its kind of like how the Ford Probe is actually a Mazda... ummm.... Yeah I can't really explain it either but it makes sense. Here read this book and it'll make sense to you too."

Respectfully yours,

Carl Rosevear

Janos_Mohacsi · February 17, 2009, 5:21pm

If you are interested about the addressing architecture only, have a look at RFC 4291: http://tools.ietf.org/html/rfc4291

If you want to have some allocation guidelines from experiences, have a look at these slides:
http://www.6deploy.org/tutorials/030-6deploy_ipv6_addressing_v0_2.pdf
http://www.6deploy.org/tutorials/031-IPv6_addr_case_RENATER_Hungarnet_v0_1.pdf
http://www.6deploy.org/tutorials/131_Campus_IPv6_deployment_consideration_v0_3.pdf

Best Regards,

Janos Mohacsi
Network Engineer, Research Associate, Head of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882

TJ1 · February 17, 2009, 5:35pm

How does IPv6 addressing work?

Short version:
2000::/3 The currently active global unicast pool
RIRx::/12 IANA (by default) assigns /12s to RIRs
RIRx:ISPx::/32 RIRs (by default) assign /32s to ISPs
RIRx:ISPx:ORGx::/48 ISPs (by default) assign /48s to enterprises
(/56s to homes)
RIRx:ISPx:ORGx:VLAN::/64 Enterprises 'subnet' their allocation into
/64s (debate over [/126 | /127] to P2P links)

I know it's been hashed and rehashed but several orgs I am associated with

are

about to ask for their allocations from ARIN and we are all realizing we

don't

really know how the network / subnet structure trickles down from the edge

to

the host. We really don't have a firm grasp of all of this as there seems

to

be multiple options regarding how many addresses should be assigned to a

host,

if the MAC address should be included in the address or if that is just for
auto-configuration purposes or what the heck the deal is. There are a lot

of

clear statements out there and a lot that are clear as mud. Unfortunately,
even when trying to analyze which RFC superseded another. Can I just

subnet it

Use the IETF/RFC web interface, clearly shows what RFCs where deprecated by,
or deprecate/update, a given doc:
e.g. - http://tools.ietf.org/html/rfc2461
... has an obsoleted by, updated by, and obsoletes ...

all like IPv4 but with room to grow or is each host really going to need

its

own /84 or something? I can't see why hosts would need any more addresses

than

today but maybe I'm missing something because a lot of addressing models

sure

allow for a huge number of unique addresses per host.

My buddy and I are about to go to Barnes and Noble, not having and luck

with

standard internet media but then we realized... how will we know if any of
that is really what we are looking for either?

Depends what you are looking for, and possibly your HW vendor of choice.

<<SNIP>>

Baker_Fred · February 17, 2009, 6:04pm

You already have a fair bit of information, but the short answer to your question is...

Apart from a few special purposes addresses (see RFC 4291), IPv6 addresses are a cross between IPv4-style CIDR addressing and XNS/IPX/ISO-style network+host addressing. Bits 0..63 of the address are a CIDR prefix; there are various guidelines on what prefix lengths should be allocated in various cases, but they are just that - unenforceable and mutable. Bits 64..127 are a host part, which may be a MAC Address, a random number, or pretty much anything else. The key thing is that the host part is unique on a LAN.

There are probably four important prefix lengths in the world - prefixes that might have special meaning, prefixes that get allocated by IANA, prefixes that get allocated by RIRs, and prefixes that get allocated to customers of ISPs. In general, IANA is treating IPv6 much like IPv4 - making sure that the RIRs have enough to work with. The RIRs are also treating IPv6 much like IPv4, with the exception that the rules require a lot less hoop-jumping. If folks need prefixes, they hand them out. The one difference is that they are trying to avoid PI addressing, as that is one of the major contributors to the current explosion of the route table (the others being "long prefixes" and "traffic engineering"). What to replace PI addressing with is a topic of ongoing discussion - various ideas have been proposed but all require some change to some business model or sacred cow somewhere, meaning that any idea that is viable gets dismissed pretty rapidly, something the folks who buy memory for routers will eventually pay the price of unless that nonsense passes. Edge networks are edge networks; they tend to assign subnets, or campuses with subnets in them.

Scott_Howard · February 17, 2009, 6:26pm

I can't help directly with your biggest question, but there's a smaller
point here that seems to come up a lot and I think is important to
address...

I can't see why hosts would need any more addresses than today but maybe
I'm missing something because a lot of addressing models sure allow for a
huge number of unique addresses per host.

According to your website your head office is located at "1333 2nd St.,
Suite 100".

Is there a 1331 2nd Street? Or a 1335? Or even a Suite 99?

Or has the street addressing system been created in a wasteful manner in
order to allow flexibility in addressing and allow the numbers themselves to
be more than just numbers?

Just like street numbers, IPv6 is a near limitless resource, which allows
for the address assigned to be more than just a simple, single address.
Yes, this results in some "waste", just like having to write "1333" in your
address where "17" might have sufficed. IPv6 assigns a /something to each
"thing", in the same way as many areas in the US simply assign 100 numbers
to each block.

In that sense IPv6 requires a mind-set change from IPv4 - you can stop
thinking in terms of the absolute minimum requirements (eg, a single IP
address in v4 because they are a scarce commodity) and start thinking about
what works best for the larger environment (such as just handing out a /64
to each network and allowing autoconfig to handle the rest). Is that
wasteful? Hell yeah! Does it matter? No!

The bigger question here is of course what size "/something", and what is a
"thing", and as recent discussions here and elsewhere have proven there's
still some contention over those questions - especially around home users.
The problem is that as an industry there simply hasn't been enough IPv6
deployment done to know what will work and what will not - or what is "best"
(for some definition of "best")

I'm sure many of us were around in the days when if even a smaller customer
wanted a network routed you were just as likely to either give them a class
C, or even to get them to register their own class C - because at the time
we thought that was the right thing to do. Over the years as the commercial
Internet grew we leant what was the "best" thing to do in most cases, and
the same business who 15 years ago was registering their own class C would
today probably get gives a single IP address - possibly even a dynamic one!
Of course the hardware also changed with the times, so that now the $30
router you can buy at Walmart has NAT, DHCP, uPNP and the ability to update
DDNS all buit in to make the model work.

Odds are what is best is going to be "best" for IPv6 will be a similar
iterative approach - the model the first round of IPv6 ISPs roll out will
probably not be the same as the one we're using in 5-10 years. Part of this
will be due to limitations in the infrastructure (not the least the
home-user CPE), but part of it of it will simply come down to experiences,
and learning what does and doesn't work well. Today you'll find numerous
RFCs and IETF drafts telling you in theory how it could/should work, but
until there's more people doing it these are little more than theory...

Scott

Jack_Bates · February 17, 2009, 6:32pm

Mohacsi Janos wrote:

If you are interested about the addressing architecture only, have a look at RFC 4291: http://tools.ietf.org/html/rfc4291

If you want to have some allocation guidelines from experiences, have a look at these slides:
http://www.6deploy.org/tutorials/030-6deploy_ipv6_addressing_v0_2.pdf
http://www.6deploy.org/tutorials/031-IPv6_addr_case_RENATER_Hungarnet_v0_1.pdf

http://www.6deploy.org/tutorials/131_Campus_IPv6_deployment_consideration_v0_3.pdf

Just to add to this, beware the vendor documentation. In particular, I noticed many "examples" posted by vendors that used all kinds of notations. Cisco, for example, formally uses /64 in current documentation but still has a ton of old docs which use /112 or other similar boundaries. Since searches don't always turn up "most current", you may find obsolete documentation.

-Jack

Owen_DeLong · February 17, 2009, 6:40pm

So, I understand the main concepts behind IPv6. Most of my peers understand. We all have a detailed understanding of most things IPv4. I have Googled and read RFCs about IPv6 for HOURS. That said, to quickly try to minimize people thinking I am an idiot who asks before he reads, I need some answers. First of all, several of my friends who feel they are rather authoritative on the subject of things network-related have given me conflicting answers. So what's the question? ...

How does IPv6 addressing work?

There are a lot of different possible answers to that question, many of which are accurate.

In general:

It's a 128 bit address. Routing is done on VLSM, but, generally for DNS purposes, these
are expected to be at least on nibble boundaries.

There is an intent to support what is known as EUI-64, which means every subnet should
be a /64, however, there are people who number smaller subnets and that is supposed
to work, but, it will break certain IPv6 things like stateless autoconfiguration (which is
optional).

I know it's been hashed and rehashed but several orgs I am associated with are about to ask for their allocations from ARIN and we are all realizing we don't really know how the network / subnet structure trickles down from the edge to the host. We really don't have a firm grasp of all of this as there seems to be multiple options regarding how many addresses should be assigned to a host, if the MAC address should be included in the address or if that is just for auto-configuration purposes or what the heck the deal is. There are a lot of clear statements out there and a lot that are clear as mud. Unfortunately, even when trying to analyze which RFC superseded another. Can I just subnet it all like IPv4 but with room to grow or is each host really going to need its own /84 or something? I can't see why hosts would need any more addresses than today but maybe I'm missing something because a lot of addressing models sure allow for a huge number of unique addresses per host.

You can subnet it just like IPv4. Each host does not need it's own subnet (/64, not /84 for the most part).
The theory behind /64 subnets was to support a way for a host to use what it already knows (MAC
address) and possibly some additional clues (Router Announcement) from the wire to configure
its own IPv6 address on an interface. Whether or not this was a good idea is still controversial, but,
whether or not it's how IPv6 is going to work is not. IPv6 is designed to work with Stateless
Autoconfiguration whether we like it or not. DHCPv6 so far is prevented from providing
default router information (or many of the other things you're used to having DHCP do)
as it currently stands.

My buddy and I are about to go to Barnes and Noble, not having and luck with standard internet media but then we realized... how will we know if any of that is really what we are looking for either?

It's a fair point. There is a good FAQ/Wiki on the ARIN web site. That may be a good place to
start.

From what I can tell, this may still be a question of great debate. Everyone seems to act like they know exactly what's going on but behind closed doors admits that they don't really know x, y, or z. I realize this is typical of my industry and even myself from time to time. J

But so I am truly reaching out here. What is the deal with IPv6 addressing and subneting? Where is the official guide to this new galaxy? I will be sure to pass this information on to my equally less clueful peers to the benefit of all of us that are making this transition.

Officially, the best summary I can give is that the subnetting model is almost identical to
IPv4, but, all subnets should be at least a /64 (and it's hard to imagine a scenario where
a single subnet should be larger, but, it can be supported).

The essential initial guidelines are:

  ISP /32
      Enough for 4billion ISPs
      Enough for each ISP to support 65,536 /48 customers or 16.7M /56 customers, etc.
      Larger ISPs can get more than a /32 if needed.

  End Site /48
      Enough for 65,536 /64 subnets
      Larger organizations can get more than a /48 if needed.

Single Subnet
/64

      Enough for more hosts that most of us can imagine on a single subnet.
      Support for 64 bit MAC addresses
      Support for stateless autoconfiguration

However, these guidelines can be violated in many circumstances to use smaller
subnets if you really want to. I don't recommend it and there's really no reason to
do so.

Finally, if we're wrong about all of this, it's OK. We can renumber people into
the other 7/8ths of the IPv6 space that are not yet issued for usage by IANA
with an entirely different numbering scheme.

There are people here at my company that seem to get it but can't seem to explain it clearly to me. To me, its basically just larger addressing space with some new logical boundaries.... But there are so many discussions of potential addressing methods that I am confused. I know from my lab setups that I can "make it work" but I'd like to "do it right". J

Hope the above helps.

I've been doing this for over 10 years now... IPv4 is native to me. If you can point me in the direction of some good, authoritative information or even say "Dood, go get IPv6 for dummies", that's fine I just need to know where to find some good information.

Unfortunately, other than the guidelines above, most of us are still experimenting
and don't have a lot of op-ex to build on.

Can someone say "well, you know how it would be nice to have like 100 different addresses on hosts to differentiate services and blah blah.... Well now that's what you account for and so then you know how a /24 almost always ends up being tight in IPv4? Right, so think of your basic bit boundaries that you adhere to as /?? And /??? In IPv6." Or "Throw all that old thought out the window. Now its kind of like how the Ford Probe is actually a Mazda... ummm.... Yeah I can't really explain it either but it makes sense. Here read this book and it'll make sense to you too."

Your basic bit boundary for a subnet really should be /64. You certainly can put
as many IP addresses on a single host as you wish and there's no reason not
to address services as you describe. There is no longer a concern about the
tightness of the subnet since a /64 is the square of the total number of hosts
that could be supported on the entire internet without network/broadcast
overhead, etc.

In IPv6, there really is no shortage of addresses and extremely little likelihood
of that ever being a problem, even with the wasteful allocation polices we
currently have in place.

Hope that helps,

Owen

(Speaking only as and for myself. This is not an official position or recommendation
from the ARIN AC. I'm just trying to help.)

Carl_Rosevear · February 17, 2009, 6:57pm

Thanks to all that responded on and off-list. My confusion is mostly cleared-up. The points that are unclear at this point are generally unclear to most people, it seems due to lack of operational experience with IPv6. Feel free to keep responding to this topic as its all very interesting but I think my needs have been met. Owen, this one from you tied it all together. Thanks all!

--Carl

Tony_Hain · February 17, 2009, 7:28pm

While people frequently claim that auto-config is optional, there are
implementations (including OS-X) that don't support anything else at this
point. The basic message is that you should not assume that the host
implementations will conform to what the network operator would prefer, and
you need to test.

One last comment (because I hear "just more bits" a lot in the *nog
community)... Approach IPv6 as a new and different protocol. If you approach
it as "IPv4 with more bits", you will trip over the differences and be
pissed off. If you approach it as a "different protocol with a name that
starts with IP" and runs alongside IPv4 (like we used to do with decnet,
sna, appletalk...), you will be comforted in all the similarities. You will
also hear lots of noise about 'lack of compatibility', which is just another
instance of refusing to recognize that this is really a different protocol.
At the end of the day, it is a packet based protocol that moves payloads
around.

Tony

Owen_DeLong · February 17, 2009, 7:48pm

While people frequently claim that auto-config is optional, there are
implementations (including OS-X) that don't support anything else at this
point. The basic message is that you should not assume that the host
implementations will conform to what the network operator would prefer, and
you need to test.

I can configure OS-X statically, so, that simply isn't true.

What is true is that there are many implementations which do not (yet)
support DHCPv6. That is not the same as "don't support anything
else".

One last comment (because I hear "just more bits" a lot in the *nog
community)... Approach IPv6 as a new and different protocol. If you approach
it as "IPv4 with more bits", you will trip over the differences and be
pissed off. If you approach it as a "different protocol with a name that
starts with IP" and runs alongside IPv4 (like we used to do with decnet,
sna, appletalk...), you will be comforted in all the similarities. You will
also hear lots of noise about 'lack of compatibility', which is just another
instance of refusing to recognize that this is really a different protocol.
At the end of the day, it is a packet based protocol that moves payloads
around.

The problem here, IMHO, stems from the fact that unlike DECnet,
Appletalk, SNA, et. al., IPv6 is intended as a replacement for
IPv4. (None of the other protocols was ever intended to replace
any of the others).

As a replacement, the IETF realized that at the current scale of the
internet when they began designing IPv6, a flag day conversion
(like what happened when we went to IPv4) was not possible.
Unfortunately, the migration plan set forth by the IETF made many
assumptions (especially on vendor preparedness and rate of
adoption prior to IPv4 runout) that have not proven out, so, the
"Everyone who has IPv4 starts running dual-stack before we
need any IPv6 only connectivity" plan is not going to prove out.

More unfortunately, there is no real contingency plan for how
migration happens absent that scenario and we are, therefore,
in for some interesting times ahead.

Owen

David_Conrad3 · February 17, 2009, 8:20pm

Unfortunately, I gather this isn't what end users or network operators want or expect. I suspect if we want to make real inroads towards IPv6 deployment, we'll need to spend a bit more time making IPv6 look, taste, and feel like IPv4 and less time berating folks for "IPv4-think" (not that you do this, but others here do). For example, getting over the stateless autoconfig religion (which was never fully thought out -- how does a autoconfig'd device get a DNS name associated with their address in a DNSSEC-signed world again?) and letting network operators use DHCP with IPv6 the way they do with IPv4.

Or, we simply continue down the path of more NATv4.

Regards,
-drc

Paul_Ferguson · February 17, 2009, 8:24pm

Isn't that the basis for the "Principle of Least Astonishment"?

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

- - ferg

Mark_Smith1 · February 17, 2009, 8:32pm

Hi,

> While people frequently claim that auto-config is optional, there are
> implementations (including OS-X) that don't support anything else at
> this
> point. The basic message is that you should not assume that the host
> implementations will conform to what the network operator would
> prefer, and
> you need to test.

I can configure OS-X statically, so, that simply isn't true.

What is true is that there are many implementations which do not (yet)
support DHCPv6. That is not the same as "don't support anything
else".

Here are a couple of implementations of DHCPv6, including one that also
works under Windows. I played with one of them on my Linux boxes a
while back (I can't remember exactly which one), and it just worked:

https://fedorahosted.org/dhcpv6/

http://klub.com.pl/dhcpv6/

Regards,
Mark.

Nathan_Ward · February 17, 2009, 8:45pm

Installable implementations don't really count if this is something my mother has to use. Perhaps an ISP gives customers a little "enabler" app to run that installs a DHCPv6 client, but that sounds nasty. Flashbacks to AOL/compuserve install disks.

SLAAC works out of the box right now for dual-stack hosts (ie. they can get DNS resolvers on v4).
That is fine for the mean time, if you are planning to go IPv6-only to end hosts then things are going to get hard, stick with IPv4 NAT for now until OS X gets DHCPv6, and people have moved off XP and older OS X boxes.

...or, until we have another way of getting resolvers that has widespread adoption..

TJ1 · February 17, 2009, 8:49pm

do this, but others here do). For example, getting over the stateless
autoconfig religion (which was never fully thought out -- how does a
autoconfig'd device get a DNS name associated with their address in a

DNSSEC-

signed world again?) and letting network operators use DHCP with IPv6 the

way

they do with IPv4.

While I wouldn't call SLAAC a religion, I will say (again) that it works in
many cases for some people, today - and whether you consider SLAAC
"half-baked" or "slim-by-design" is a subjective matter.

In the meantime, I am also a proponent for letting ops use DHCPv6 ...
especially DHCPv6-PD!

Mark_Smith1 · February 17, 2009, 8:54pm

Alternatively, you can say, "if we're going to put effort into making
these one or two changes (e.g. making IPv4 addresses bigger), is
there an opportunity to make other improvements." Change always has a
cost, so I think maximising the benefits from that cost, by considering
additional changes at the same time, is of value.

Some might say this is "second system syndrome." I think that only
qualifies if you aren't ruthless in deciding which additional changes
you make verses their additional costs vs benefits.

The Internet's success isn't really attributable to IPv4, much like a
road's success isn't really attributable to whether it is made of
bitumen or concrete. The Internet's success is attributable to whom
and to what it has and does provide connectivity to. IPv4 has been a
good material to build the Internet from over the last 20 to 30 years,
but there are limitations with it, and some other improvements,
such as node autoconfiguration, proven useful in protocols mostly
designed since IPv4 was, such as XNS, IPX, Appletalk and DECNET, can't
be accomodated in it.

I think IPv6 is similar enought to IPv4 that what you know about IPv4
can help you learn IPv6, but different enough that you shoudln't just
consider IPv6 to be IPv4 with bigger addresses. Some principles and
models are the same, some are similar, some are different.

Anyway, that's the way I think about IPv6 vs IPv4.

Regards,
Mark.

Nathan_Ward · February 17, 2009, 9:05pm

Having taught a bunch of IPv6 courses opening with a photo of Gaurab and his "96 more bits, no magic" tshirt and then having dealt with the confusion once we get in to the nitty gritty details, I am inclined to agree with you here.

The intention of these sorts of statements is to remove the "I will have to learn IP all over again" fear (and the associated "it's too hard" etc.), but you are right, this has been causing people to get a bit surprised when stuff does not work the same as IPv4.

I suppose it is fair to say that in the core of the network, it is essentially 96 more bits, and no magic. The access network is where this becomes a bit of a confusing statement.

Anyway, comments taken on board, I'll have a think about how to do this differently.

Joe_Provo4 · February 17, 2009, 10:02pm

[snip]

starts with IP" and runs alongside IPv4 (like we used to do with decnet,
sna, appletalk...), you will be comforted in all the similarities. You will

This is highly amusing, as for myself and many folks the experience
of these 'other protocols', when trying to run in open, scalable,
and commercially-viable deployments, was to encapsulate in IP(v4)
at the LAN/WAN boundary. It is no wonder that is the natural reaction
to IPv6 by those who have survived and been successful with such
operational simplicity.

Cheers,

Joe

Tony_Hain · February 17, 2009, 10:14pm

Owen DeLong wrote:

> While people frequently claim that auto-config is optional, there are
> implementations (including OS-X) that don't support anything else at
> this
> point. The basic message is that you should not assume that the host
> implementations will conform to what the network operator would
> prefer, and
> you need to test.

I can configure OS-X statically, so, that simply isn't true.

What is true is that there are many implementations which do not (yet)
support DHCPv6. That is not the same as "don't support anything
else".

Fair enough about OS-X, but that is not the only non-dhcpv6 implementation
out there. How exactly do you configure a static address on a sensor with no
UI?

My point was 'don't assume', & test.

>
>
>
> One last comment (because I hear "just more bits" a lot in the *nog
> community)... Approach IPv6 as a new and different protocol. If you
> approach
> it as "IPv4 with more bits", you will trip over the differences and
be
> pissed off. If you approach it as a "different protocol with a name
> that
> starts with IP" and runs alongside IPv4 (like we used to do with
> decnet,
> sna, appletalk...), you will be comforted in all the similarities.
> You will
> also hear lots of noise about 'lack of compatibility', which is just
> another
> instance of refusing to recognize that this is really a different
> protocol.
> At the end of the day, it is a packet based protocol that moves
> payloads
> around.
>
The problem here, IMHO, stems from the fact that unlike DECnet,
Appletalk, SNA, et. al., IPv6 is intended as a replacement for
IPv4. (None of the other protocols was ever intended to replace
any of the others).

As a replacement, the IETF realized that at the current scale of the
internet when they began designing IPv6, a flag day conversion
(like what happened when we went to IPv4) was not possible.
Unfortunately, the migration plan set forth by the IETF made many
assumptions (especially on vendor preparedness and rate of
adoption prior to IPv4 runout) that have not proven out, so, the
"Everyone who has IPv4 starts running dual-stack before we
need any IPv6 only connectivity" plan is not going to prove out.

More unfortunately, there is no real contingency plan for how
migration happens absent that scenario and we are, therefore,
in for some interesting times ahead.

Whine, whine, whine... we are where we are, and no amount of whining will
change the fact that people outside of Japan chose not to think ahead. The
primary point of dual-stack was to decouple the requirement for the end
systems to change all the apps at once. Most of the *nog community doesn't
get, or care to get, the costs of the end system operations staff because
they are focused on the costs related to moving the bits around. There are
tunneling functions defined, so you don't have to get 'dual-stack
everywhere' before you can take another step. Those are not as 'efficient'
as dual-stack when moving the bits around, and require operational
management, but that is a cost trade-off that can be made. People that
insist on delivering only one version will force unnatural acts at the edge,
while delivering both will allow people to move at their own pace.

Like it or not, the end systems are moving without the *nog community. Fire
up uTorrent and see how many 6to4 & teredo connected peers you end up with
(I am generally seeing about 1/4-1/3 of the set). This is 'real dual-stack
at the edge', and works around the laggard ISP deployments. The Internet was
built by tunneling over the laggard telco's using the voice technology
available, and the next generation of it will be built the same way if the
*nog community buries its head in the same dark place that the telco's did.

Tony

Tony_Hain · February 17, 2009, 10:17pm

David Conrad wrote:

> Approach IPv6 as a new and different protocol.

Unfortunately, I gather this isn't what end users or network operators
want or expect. I suspect if we want to make real inroads towards
IPv6 deployment, we'll need to spend a bit more time making IPv6 look,
taste, and feel like IPv4 and less time berating folks for "IPv4-
think" (not that you do this, but others here do).

I am not trying to berate anyone, just point out that your starting
perspective will impact how you see the differences. From what I have seen,
people are generally happy when they find similarities, and pissed off when
the find differences. Therefore, if you start by assuming it is different,
you will be much happier.

For example,
getting over the stateless autoconfig religion (which was never fully
thought out -- how does a autoconfig'd device get a DNS name
associated with their address in a DNSSEC-signed world again?) and
letting network operators use DHCP with IPv6 the way they do with IPv4.

There are many religious positions here, and none are any more valid than
the others. At the end of the day, each approach needs to be complete and
stand-alone, but due to religious fighting, all approaches are required to
exist at once for anything to work.

This being a list of network engineers, there is a strong bias toward tools
that allow explicit management of the network. This is a fine position, and
those tools need to exist. There are others that don't want, or need to know
about every bit on the wire, where 'as much automation as possible' is the
right set of tools. Infighting at the IETF kept the RA from informing the
end systems about DNS, and kept DHCPv6 from informing them about their
router. The result is that you have to do both DHCP & RA, when each should
be capable of working without the other.

As far as dnssec, while the question is valid, blaming the IPv6 design for
not considering something that 10+ years later is still not
deployed/deployable, is a bit of a stretch. This all comes down to trust
anchors, and personally I question the wisdom of anyone that considers DHCP
to be a valid trust anchor. It gets that status because it is something
tangible that is reasonably well understood, but there is nothing in its
design, or the way that it is deployed in practice that makes it worthy of
anything related to trust. An out-of-band trust cert between an
auto-configured end system and a ddns service makes much more sense than a
DHCP service based on believing that the end system will not bother to spoof
its mac address.

Or, we simply continue down the path of more NATv4.

While this is the popular position, those that have thought about it realize
that what works for natv4 at the edge, does not work when that nat is moved
toward the core. If people really go down this path, the end applications
will do even more levels of tunneling over the few things that work, and the
network operators will lose all visibility into what is really going on
(IPv6 tunnel servers are just the modern modem pools, and tunneling over
http will become more common if that is the only path that works).

Tony