IPv6 news

Mailman List Mirror (Read Only)
1

Forgot sub to nanog-post..

I _really_ wish people would stop saying '"unlimited"' or 'almost
infinite' when talking about IPv6 address space. It simply isn't
true, even in the theoretical sense, and particularly given how
address space is being allocated now. It also gives many people the
wrong impression: that IPv6 addresses will mean every grain of sand
in the Universe (or whatever) can have portable address space.

Am I mistaken in thinking that if shim6 (or something like it) did
exist, that portable address space could be allocated to everyone (maybe
with a different allocation policy?) to be used as (shim6) identifiers.
Then, a number of years down the line, if the company met certain
criteria they could get an ASN and announce the portable address space
as routing prefix if they desired?

John

2

Yes, you're mistaken. The locator identifier is chosen from the host's pool of upper-layer identifiers.

Many people speculating and asking questions in this thread would do very well to take a quick read through this high-level description:

   http://www.ietf.org/internet-drafts/draft-ietf-shim6-arch-00.txt

Note also (as Susan mentioned) the IAB is facilitating a BOF on IPv6 multi-homing in Los Angeles, for those who are planning to attend.

Joe

3

> Am I mistaken in thinking that if shim6 (or something like it) did
> exist, that portable address space could be allocated to everyone
> (maybe
> with a different allocation policy?) to be used as (shim6)
> identifiers.

Yes, you're mistaken. The locator identifier is chosen from the
host's pool of upper-layer identifiers.

Sorry, maybe I wasn't clear when I said identifier - I meant endpoint
identity (ULID) not locator.

I had read a portion (most of the first 3 sections) of draft-ietf-shim6-
arch-00.txt to try and get the main concepts. Just so I get it
straight, as I've read it, there are ULIDs (which I mistakenly called
identifiers in my previous posts), and there are locators (which are
real routable IP addresses).

From section 3:

   "There are a number of options in the choice of an endpoint identity
   realm, including the use of existing addresses as an identity tokens,
   the use of distinguished (possibly non-routeable) addresses as
   tokens, or the use of tokens drawn from a different realm (such as
   use of a fully qualified domain name).

   Shim6 uses the first of these options, and the endpoint identity for
   a host is one of the locator addresses that are normally associated
   with the host. The particular locator address selected to be the
   endpoint identity (or ULID) is specified in [RFC3484]. Shim6 does
   not mandate the use of distinguished addresses as identities,
   although the use non-routeable distinguished addresses in this
   context is described as an option in this approach."

So currently, shim6 will always use a routable IP address (one of the
locators) as the ULID, but it seemed to leave the option open for non-
routable addresses to be used. Therefore, my conclusion that a portable
(but non-routed) address might be used.

.....

And now, after reading the rest of the draft, I see that use of non-
routable addresses has only been explored at an abstract level.
Obviously the null tranform for ULID->locator wouldn't work when
establishing a session if the ULID was non-routable.

One comment/question and I know this is probably the wrong forum, but in
section 4.1 there is a question "What form of token is passed to the IP
layer from the upper level protocol element as an identification of the
remote session target?". As part of the answer, it says "If the initial
identification of the remote host is via a domain name, then this
approach assumes that there are a one or more locators held in the
DNS."

Should that not read that "there are one or more ULIDs held in DNS"?
Although in practice, it seems that the set of ULIDs and locators will
probably be the same (although not always?) so it probably won't matter
much.

John

4

Oops -- I meant "the upper-layer identifier is chosen from the host's pool of locators". Must Not Post Before Coffee.

Joe

5

there would seem to be two paths here.

the one we are currently walking has more and more complexity
to try to deal with the lack of reality-based design in v6.
every step, instead of making things simpler, adds more
complexity to deal with the mistakes of old narrow decisions.

consider an alternative. v6 is barely deployed at all, maybe
1/(10^6) of what it will be. so, a change that seems very
expensive now will be trivially amortized if it saves later,
while a cost that increases in time (shim6, 6to4, ...) will
cost us massively in the future.

so, if we had a free hand and ignored the dogmas, what would we
change about the v6 architecture to make it really deployable
and scalable and have compatibility with and a transition path
from v4 without massive kludging, complexity, and long term
cost?

you can pay me now or pay me later. but later, everything
costs a million times as much.

randy

6

Okay, I'll bite - If I were king, here's what I'd want
to see:

I'd change the allocation approach: rather than give
every customer a /64, which represents an IPv4
universe full of IPv4 universes, I'd think that any
customer can make do with a single IPv4-size universe,
and make the default end-customer allocation a /96.
ISPs could still get gigantic prefixes (like a /23 or
something), to make sure that an ISP would never need
more than one prefix.

I'd move us to the 1-prefix-per-ASN approach as much
as possible - reserve a single /16 for multihoming
end-sites, and let that be a swamp. There are under
32K multihomed ASNs in use now, and while demand is
growing, if we can keep organizations to one prefix
each, the routing table stays pretty darn small.

Designate a /96 as "private" space for use on devices
which don't connect to the Internetv6.

To qualify for an "ISP" allocation, an entity would
have to agree to route the swamp space, and not route
the "private" space.

And as long as I'm dreaming, I'd like a pony...

-David Barak-
-Fully RFC 1925 Compliant-

7

Okay, I'll bite - If I were king, here's what I'd want
to see:

[ changes to current policies, not architecture, elided ]

let's first agree on some goals

  o really big address space, not the v6 fixed 32 bit
    limited game. (old dogs will now bay for variable
    length, aroooooo!)

  o a routing system which has the ability to scale really
    well in the presence of fewer and fewer nodes (think
    sites) where out-degree == 1

  o mobility

  o really scalable v4 backward compatibility so that we
    don't have the end-user-affecting mess which looms in a
    few years

anything else?

randy

8

  o really big address space, not the v6 fixed 32 bit

s/32/64/

sorry

9

> Okay, I'll bite - If I were king, here's what I'd want
> to see:

[ changes to current policies, not architecture, elided ]

let's first agree on some goals

  o really big address space, not the v6 fixed 32 bit
    limited game. (old dogs will now bay for variable
    length, aroooooo!)

  woof!

  o a routing system which has the ability to scale really
    well in the presence of fewer and fewer nodes (think
    sites) where out-degree == 1

  sure... maybe. is there the presumption of e2e here?

  o mobility

  process mobility? latency tolerent? any distinction
  btwn individual nodes or whole networks? need clarity here.

  o really scalable v4 backward compatibility so that we
    don't have the end-user-affecting mess which looms in a
    few years

  well... not so sure about this one. why do we care?

10

I'd change the allocation approach: rather than give
every customer a /64, which represents an IPv4
universe full of IPv4 universes, I'd think that any
customer can make do with a single IPv4-size universe,
and make the default end-customer allocation a /96.

I personally am in favor of reducing minimum allocations like this -
and as was discussed quite extensively in the "botnet of toasters and
microwave ovens when you ipv6 enable the lot" thread a few weeks back,
it usually ends up that there's just one host in a /48 or /64 so that
the sparsely populated v6 address space means bots cant go scanning IP
space for vulnerable hosts like they do in v4

It also means that when Vint Cerf's research about extending the
internet into outer space comes through (or when we finally start
exchanging email, http or whatever traffic with aliens), there's
sooner or later going to be an intergalactic assembly of some sort
where delegations from Betelgeuse and Magrathea will complain about
how those @^$^$#^$^ earthlings hogged all the v6 space thinking
there's more than enough v6 IP space to allot a /48 to every single
molecule on earth, so now they're not getting enough IP space to
network a group of computers that'll plot the answer to life, the
universe and everything.

Well, I know that sounds silly, but people were handing out class A, B
and C space for years thinking nobody at all would run out of v4
space, there's lots of it so why not just parcel it out with open
hands.

Back to operations - there was this interesting proposal - well, two
proposals as it turned out - at apnic 20 -
http://www.apnic.net/meetings/20/report.html

    * prop-031-v001: Proposal to amend APNIC IPv6 assignment and
utilisation requirement policy
          o During the discussions, the proposer agreed to a request to separate
into two proposals:
                + Proposal part 1: Evaluation for subsequent allocations to be
based on an HD-Ratio value of 0.94
                      # The proposal reached consensus at the Policy SIG meeting
and AMM and has now been referred to the sig-policy mailing list for the
next stage in the policy development process.
                + Proposal part 2: Add a /56 end-site allocation point (in addition
to /64 and /48) and default end-site allocation for SOHO end site to be a /56
                      # This proposal did not reach consensus at the Policy SIG
meeting.

--srs

11

  o a routing system which has the ability to scale really
    well in the presence of fewer and fewer nodes (think
    sites) where out-degree == 1

sure... maybe. is there the presumption of e2e here?

i think so, for various valies of e2e

  o mobility

process mobility? latency tolerent? any distinction
btwn individual nodes or whole networks? need clarity here.

i think the user is gonna expect application binding mobility

  o really scalable v4 backward compatibility so that we
    don't have the end-user-affecting mess which looms in a
    few years

well... not so sure about this one. why do we care?

becuse isps have these folk called users who pay us money to
see that they get the full internet (and let's not go down
the silly rat hole of cogent vs level(3), thank you).

randy

12

> Hopefully, that will reach a point where the operators show up and
> participate at IETF, rather than the IETF coming to NANOG.
>

agreed.

Full ack. Ops should really realize that they can have a lot of
influence in the processes and what is actually being standardized.
Which really helps the ops a lot as they then have an extra foot in
the door at the Vendors, as the IETF is also known as the IVTF as some
people like to call it :slight_smile:

> I'd change the allocation approach: rather than give
> every customer a /64, which represents an IPv4
> universe full of IPv4 universes, I'd think that any
> customer can make do with a single IPv4-size universe,
> and make the default end-customer allocation a /96.

I personally am in favor of reducing minimum allocations like this -
and as was discussed quite extensively in the "botnet of toasters and
microwave ovens when you ipv6 enable the lot" thread a few weeks back,
it usually ends up that there's just one host in a /48 or /64 so that
the sparsely populated v6 address space means bots cant go scanning IP
space for vulnerable hosts like they do in v4

There is a current document out for trying to get this stepped back to
a /56 for _enduser_ sites. Corporate / Organisational / Business sites
should then still get a /48.

HD ratio docs:
http://www.ripe.net/ripe/policies/proposals/2005-1.html
http://www.ripe.net/ripe/policies/proposals/2005-08.html

Endsite definition:
http://www.ripe.net/ripe/policies/proposals/2005-4.html

As a note, out of my IPv6 /48, at home, I only use one /64 as I bridged
the wireless and wired networks. This was easier than having Samba do
remote announces to the other /64 and also allows me to re-attach my
laptop and plug it into the wired without it changing the IP, very cheap
'mobility' :slight_smile: A /56 for 'home usage', thus having 2^8 = 256 /64's or
subnets would IMHO (force me to drink beer when this ever turns out to
be wrong :slight_smile: be enough for most home usages. I really don't see people
installing 200+ routed networks in a home. Most people don't even have
more than 4 rooms and one /64 already contains 2^64 addresses, unless we
go for the IP-per-carpet-fiber approach, just give the carpet in your
house a single /64 and you still have 255 subnets to go...

It also means that when Vint Cerf's research about extending the
internet into outer space comes through (or when we finally start
exchanging email, http or whatever traffic with aliens), there's
sooner or later going to be an intergalactic assembly of some sort
where delegations from Betelgeuse and Magrathea will complain about
how those @^$^$#^$^ earthlings hogged all the v6 space thinking
there's more than enough v6 IP space to allot a /48 to every single
molecule on earth, so now they're not getting enough IP space to
network a group of computers that'll plot the answer to life, the
universe and everything.

They don't need to, this computer is already there, it is Earth.....
there just ain't no plotter installed and we will be destroyed for that
superhighway and then re-built as Earth 2, but we won't notice that :slight_smile:

Well, I know that sounds silly, but people were handing out class A, B
and C space for years thinking nobody at all would run out of v4
space, there's lots of it so why not just parcel it out with open
hands.

The Huitema-Durand / Host-Density (HD) ratio RFC3194 it explains quite a
number of these issues and covers most of them.

Next to that note that 2000::/3 is only 1/8th of the total IPv6 address
space. If we peep up, we can do that 8 times before the address space is
full and I am quite sure if 2000::/3 runs out that people will start
having some really loud discussions. Indeed 2000::/3 would then be
similar to 'class A' space...

Back to operations - there was this interesting proposal - well, two
proposals as it turned out - at apnic 20 -
http://www.apnic.net/meetings/20/report.html

Similar to the one done above in the RIPE region :slight_smile:

Greets,
Jeroen

13

Hi David,

<snip>

I'd change the allocation approach: rather than give
every customer a /64, which represents an IPv4
universe full of IPv4 universes, I'd think that any
customer can make do with a single IPv4-size universe,
and make the default end-customer allocation a /96.
ISPs could still get gigantic prefixes (like a /23 or
something), to make sure that an ISP would never need
more than one prefix.

If we're going to do that, we may as well also start reclaiming those 48
bit MAC addresses that come with ethernet cards. After all, nobody would
need anymore than say 12 to 13 bits to address their LANs.

Hmm, so what do 48 bit addresses give us that 12 bits don't ? How about
convenience. It is convenient to be able to plug in an ethernet card,
and, excepting the very rare occasions when a manufacturer has stuffed
up, be assured that you can just plug it in and it works. No jumpering,
no maintaining a LAN address registry per segment, no address
collisions, or at least extremely rare ones.

From what I understand, it is considered that 48 bit MAC addresses will

be too small for our convenience needs of the future, so IEEE have
invented 64 bit ones (EUI-64s).

Wouldn't it be nice to the same sort of convenience in a new layer 3
protocol that we've had since 802.3 was first published (and since I
started working in networking 1993) ? I'd like it, and I'm willing to
pay a few bytes in the src and dst addresses in my layer 3 protocol
header for it.

/64s in IPv6 for multi-access segments (i.e. everything other than
single address loopbacks) is convenient and useful, and I think should
be kept.

Regards,
Mark.

14

If we're going to do that, we may as well also start reclaiming
those 48 bit MAC addresses that come with ethernet cards. After
all, nobody would need anymore than say 12 to 13 bits to address
their LANs.

so you think that layer-2 lans scale well above 12-13 bits?
which ones in particular?

randy

15

Hi Randy,

> If we're going to do that, we may as well also start reclaiming
> those 48 bit MAC addresses that come with ethernet cards. After
> all, nobody would need anymore than say 12 to 13 bits to address
> their LANs.

so you think that layer-2 lans scale well above 12-13 bits?
which ones in particular?

Maybe you've missed my point. Nobody (at least that I'm aware of)
_needs_ 48 bits of address space to address nodes their LANs. We didn't
get 48 bits because we needed them (although convenience is a need, if
it wasn't we'd still be hand winding our car engines to start them ). We
got them because it made doing other things much easier, such as (near)
guarantees of world wide unique NIC addresses, allowing "plug-and-play",
at least a decade before the term was invented.

I've read somewhere that the original ethernet address was only 16 bits
in size. So why was it expanded to 48 bits ? Obviously people in the 80s
weren't running LANs with 2^48 devices on them, just like they aren't
today.

Why have people, who are unhappy about /64s for IPv6, been happy enough
to accept 48 bit addresses on their LANs for at least 15 years? Why
aren't people complaining today about the overheads of 48 bit MAC
addresses on their 1 or 10Gbps point-to-point links, when none of those
bits are actually necessary to identify "the other end" ? Maybe because
they have unconsciously got used to the convenience, and, if they've
thought about it, realise that the byte overhead/cost of that
convenience is not worth worrying about, because there are far higher
costs elsewhere in the network (including administration of it) that
could be reduced.

Regards,
Mark.

16

Mark Smith wrote:

We didn't
get 48 bits because we needed them (although convenience is a need, if
it wasn't we'd still be hand winding our car engines to start them ). We
got them because it made doing other things much easier, such as (near)
guarantees of world wide unique NIC addresses, allowing "plug-and-play",
at least a decade before the term was invented.

This is not a scientific opinion but I think you can pick a random host
id from 32 bit space on most lans without having to retry very often.

- Kevin

17

From an end-user:

I dont know what I should need an /64 for but it's barf, barf anyhow.

My routing table is telling me I have got a /124 only:

The tunnel (network) *::0
The end of the tunnel *::1
Me *::2
The tunnel broadcast *::3

Right now I have the impression we are only enusers.
Right now I have the impression we are all connected to the same
university PC running BSD something.

Ok, today I have some NATted stuff that would be fond of its own
ip. Kicking my NAT-box out I could grow my hair again. No more
worring who needs what port and why.

Beware!

Who is printing all those bank listings on my new printer. It
was a wholesale networkprinter. Just plug it into the power
and print. Must have been stolen from the bank of china because
it is all chines companies.

And why is that van with the ice cream waiting in front of my
neighour? It is me who ordered the icream. They have thrown
out their freecer. I dont know why. It was working perfectly.
I had no problems connecting it to my wlan and ordering. They
did not even care about my bank account beeing empty. They told
me I had enough credit to by their company.

Sorry I have to stop now. Some policemen want to talk with me
about a major fraud done with my IPv6 tunnel.

See you later :slight_smile:

Jeroen Massar wrote:

18

--- snip ---

Sorry I have to stop now. Some policemen want to talk with me
about a major fraud done with my IPv6 tunnel.

See you later :slight_smile:

no, they're just there to help out the guys in the white lab coats holding an odd-looking jacket. better late than never, i guess. we'll come visit (not really).

:wink:

19

Mohacsi Janos wrote:

From an end-user:

I dont know what I should need an /64 for but it's barf, barf anyhow.

My routing table is telling me I have got a /124 only:

The tunnel (network) *::0
The end of the tunnel *::1
Me *::2
The tunnel broadcast *::3

What? Broadcast?

Well, it is singlecast :slight_smile:

ping *::3 and 1 answers.

ping *::1 ok 1 answers.

ping *::2 nobody answers - that is my configuration problem.

ping *::0 nobody answers

20

--- Mark Smith
<random@72616e646f6d20323030342d30342d31360a.nosense.org>
wrote:

Why have people, who are unhappy about /64s for
IPv6, been happy enough
to accept 48 bit addresses on their LANs for at
least 15 years? Why
aren't people complaining today about the overheads
of 48 bit MAC
addresses on their 1 or 10Gbps point-to-point links,
when none of those
bits are actually necessary to identify "the other
end" ? Maybe because
they have unconsciously got used to the convenience,
and, if they've
thought about it, realise that the byte
overhead/cost of that
convenience is not worth worrying about, because
there are far higher
costs elsewhere in the network (including
administration of it) that
could be reduced.

Wrong issue. What I'm unhappy about is not the size
of the address - you'll notice that I didn't say "make
the whole address space smaller." What I'm unhappy
about is the exceedingly sparse allocation policies
which mean that any enduser allocation represents a
ridiculously large number of possible hosts. The only
possible advantage I could see from this is the
protection against random scanning finding a user -
but new and fun worms will use whatever mechanism the
hosts use to find each other: I guarantee that the
"find a printer" function won't rely on a sequential
probe of all of the possible host addresses in a /64
either...

Also, the 64-bit addressing scheme is sized to include
the MAC address, right? Why would encoding L2 data
into L3 be a good thing? The conceptual problem that
I have had with v6 from the beginning is that it's not
trying to optimize a single layer, it's really trying
to merge several layers into one protocol. Ugh.

-David Barak-
-Fully RFC 1925 Compliant-

David Barak
Need Geek Rock? Try The Franchise:
http://www.listentothefranchise.com