Re: IPv6 daydreams
--- David Conrad <[EMAIL PROTECTED]> wrote: > On Oct 17, 2005, at 10:39 PM, Paul Jakma 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. > > 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/
Re: IPv6 daydreams
On Oct 17, 2005, at 10:39 PM, Paul Jakma 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. I believe the complaint isn't about what _can be_ done, rather what _is being_ done. 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. Rgds, -drc
Re: IPv6 daydreams
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 [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: If swimming is so good for your figure, how do you explain whales?
Re: IPv6 daydreams
On Mon, 2005-10-17 at 04:43 -0700, David Barak wrote: > 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. See the HD ration + proposals about sizing it down to a /56 as mentioned in my previous mail to this list. > 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... SDP, uPnP, DNSSD etc and most likely also using ff02::1 and other multicast tricks. The important thing here though is that you already have a local address > 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? Because this gives you an automatic unique IP address. Also some L2's (firewire comes to mind) have 64 bit EUI's. > 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. One could, at least in theory and afaik not tried yet, run IPv6 as L2 :) Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: IPv6 daydreams
--- Mark Smith <[EMAIL PROTECTED]> 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/
Re: IPv6 daydreams
Mohacsi Janos wrote: On Mon, 17 Oct 2005, Peter Dambier 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 :) ping *::3 and 1 answers. ping *::1 ok 1 answers. ping *::2 nobody answers - that is my configuration problem. ping *::0 nobody answers 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 :) Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 Jeroen Massar wrote: On Mon, 2005-10-17 at 02:52 +, 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 <[EMAIL PROTECTED]> 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 t
Re: IPv6 daydreams
- Original Message - From: "Peter Dambier" <[EMAIL PROTECTED]> To: "Jeroen Massar" <[EMAIL PROTECTED]> Cc: "Suresh Ramasubramanian" <[EMAIL PROTECTED]>; "Tony Li" <[EMAIL PROTECTED]>; "Daniel Roesen" <[EMAIL PROTECTED]>; "Christoper L. Morrow" <[EMAIL PROTECTED]>; Sent: Monday, October 17, 2005 5:43 AM Subject: Re: IPv6 daydreams --- 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 :) 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). ;) --- paul galynin
Re: IPv6 daydreams
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 +, 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 <[EMAIL PROTECTED]> 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 addre
Re: IPv6 daydreams
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
Re: IPv6 daydreams
Hi Randy, On Sun, 16 Oct 2005 23:08:49 -1000 Randy Bush <[EMAIL PROTECTED]> 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.
Re: IPv6 daydreams
> 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
Re: IPv6 daydreams
Hi David, On Sun, 16 Oct 2005 16:49:25 -0700 (PDT) David Barak <[EMAIL PROTECTED]> 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. > 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.
Re: IPv6 daydreams
On Mon, 2005-10-17 at 02:52 +, 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 <[EMAIL PROTECTED]> 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 signature.asc Description: This is a digitally signed message part
Re: IPv6 daydreams
>> 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
Re: IPv6 daydreams
On 17/10/05, David Barak <[EMAIL PROTECTED]> 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
Re: IPv6 daydreams
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, aroo!) 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
Re: IPv6 daydreams
> o really big address space, not the v6 fixed 32 bit s/32/64/ sorry
Re: IPv6 daydreams
> 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, aroo!) 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
IPv6 daydreams
--- Randy Bush <[EMAIL PROTECTED]> wrote: > 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? 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- __ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs
