On Sun, 2005-10-16 at 11:08 -0400, Joe Abley wrote:

...

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.

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,

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). 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

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

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

On Sun, Oct 16, 2005 at 05:20:12PM -1000, Randy Bush wrote:

...

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?

anything else?

randy

On 17/10/05, David Barak <thegameiam@yahoo.com> wrote:

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

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 :) Jeroen Massar wrote:

On Mon, 2005-10-17 at 02:52 +0000, Christopher L. Morrow wrote:

...

On Sat, 15 Oct 2005, Tony Li wrote:

...

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 :)

On Mon, 2005-10-17 at 09:15 +0530, Suresh Ramasubramanian wrote:

...

On 17/10/05, David Barak <thegameiam@yahoo.com> wrote:

...

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' :) 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 :) 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 :)

...

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 :)

Greets, Jeroen

-- Peter and Karin Dambier Public-Root Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-179-108-3978 (O2 Genion) +49-6252-750308 (VoIP: sipgate.de) mail: peter@peter-dambier.de mail: peter@echnaton.serveftp.com http://iason.site.voila.fr http://www.kokoom.com/iason

Hi David, On Sun, 16 Oct 2005 16:49:25 -0700 (PDT) David Barak <thegameiam@yahoo.com> wrote:

<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. -- The Internet's nature is peer to peer.

Hi Randy, On Sun, 16 Oct 2005 23:08:49 -1000 Randy Bush <randy@psg.com> wrote:

...

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. -- The Internet's nature is peer to peer.

--- 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 __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/

On Mon, 17 Oct 2005, David Barak wrote:

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

You can allocate to 100% density on the network identifier if you want, right down to /64. The host identifier simply is indivisible, and just happens to be 64bit. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: If swimming is so good for your figure, how do you explain whales?

--- David Conrad <drc@virtualized.org> wrote:

...

...

Wrong issue. What I'm unhappy about is not the size of the address - you'll notice that I didn't say "make

On Oct 17, 2005, at 10:39 PM, Paul Jakma wrote: the whole address

...

...

space smaller." What I'm unhappy about is the exceedingly sparse allocation policies You can allocate to 100% density on the network identifier if you want, right down to /64.

I believe the complaint isn't about what _can be_ done, rather what _is being_ done.

Yes and yes. I am certainly complaining about what *is* being done. See below for my bigger issue.

...

The host identifier simply is indivisible, and just happens to be 64bit.

I've always wondered why they made a single "address" field if the IPv6 architects really wanted a hard separation between the host identifier and the network identifer. Making the "address" a contiguous set of bits seems to imply that the components of the "address" can be variable length.

Now we're cooking with gas: what we've learned from MAC addresses is that it's really nice to have a world-unique address which only has local significance. The /64 "host identifier" is a misnomer: there are folks who use /127s and /126s for point-to-point links, and there are all sorts of variable length masks in use today. The whole reason for a /64 to be associated with a host is to have enough room to encode MAC addresses. I ask again - why exactly do we want to do this? Layer-2 works just fine as a locally-significant host identifier, and keeping that out of layer-3 keeps everything considerably simpler. -David Barak- -Fully RFC 1925 Compliant- __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/