Policy Proposal #eta : IPv6 Address Allocation and Assignment Policy - definition for "End-Site
Dear Address Policy WG, Please find enclosed a policy proposal from Eric Schmidt. This proposal is entered into the discussion phase with a deadline of 4 weeks - August 10th. Best Regards, Hans Petter Holen AC Chair 1.Number: #Eta 2.Policy Proposal Name: IPv6 Address Allocation and Assignment Policy - definition for "End-Site" 3.Author a.name: Eric Schmidt b.e-mail: erics@t-com.net c.telephone: ++49 441 234 4592 d.organisation: Deutsche Telekom AG 4.Proposal Version: 5.Submission Date: 2005-05-13 6.Suggested WG for discussion and publication: address-policy-wg or ipv6-wg 7.Proposal type: modify a.new, modify, or delete. 8.Policy term: permanent a.temporary, permanent, or renewable. 9.Summary of proposal There are various terms for "end-site" in the IPv6 allocation and assignment policy (ripe-267) and the RFC3177. We need to have a finally definition for "end-site" to establish clear internal assignment policies 10. Policy text a.Current (if modify): 2.9. End Site An End Site is defined as an End User (subscriber) who has a business relationship with a service provider that involves: that service provider assigning address space to the End User that service provider providing transit service for the End User to other sites that service provider carrying the End User's traffic that service provider advertising an aggregate prefix route that contains the End User's assignment b.New: 2.9 End Site End-Site defines a customer´s network with an own link to the ISP. The customer could run various networks on different locations (e.g. multiple branches). As long as the networks are all independent and have no internal connection, each network is defined as a single end-site. If the networks have internal connection and only one common link to the ISP, these networks are summarized to one end-site. 2.9a A customer is an End User (subscriber) who has a business relationship with a service provider that involves: that service provider assigning address space to the End User that service provider providing transit service for the End User to other sites that service provider carrying the End User's traffic that service provider advertising an aggregate prefix route that contains the End User's assignment 11. Rationale: a.Arguments supporting the proposal At last we will have a concrete definition for end-site. There are a lot of discussions even in different RIR regions and as far as i know non of this has reached an conclusion. The rfc3177 defines end site as single edge networks, this is pretty close to my proposal and i think it is easier to update a RIPE policy than an rfc. This question was discussed in the IPv6 maillist before and it looks like that this definition could get a majority approval In the IPv6 End User Site Assignment Request Form (ripe-308) the requester has to confirm that he read the policy document. It is hard for a customer to understand these improper terms. This proposal should not be combined with the /48 /56 discussion which is on at the moment. It´s just a matter of definition b.Arguments opposing the proposal i can´t see anything against this .....
On Sun, 2005-07-10 at 13:07 +0200, Hans Petter Holen wrote: <SNIP>
2.9. End Site An End Site is defined as an End User (subscriber) who has a business relationship with a service provider that involves:
that service provider assigning address space to the End User
This line already describes a site.
that service provider providing transit service for the End User to other sites that service provider carrying the End User's traffic that service provider advertising an aggregate prefix route that contains the End User's assignment
These three specify a site using the upstream, which might not be necessary. There are actually sites on this planet (and maybe others ;) that need address space and are never going to connected to the Internet. These last three sentences cause that those sites can't get address space. What should they do, use some random number? Greets, Jeroen
These three specify a site using the upstream, which might not be necessary. There are actually sites on this planet (and maybe others ;) that need address space and are never going to connected to the Internet.
classically, if they have no plan to be connected, they don't get address space. randy
On Sun, Jul 10, 2005 at 08:38:48AM -1000, Randy Bush wrote:
These three specify a site using the upstream, which might not be necessary. There are actually sites on this planet (and maybe others ;) that need address space and are never going to connected to the Internet.
classically, if they have no plan to be connected, they don't get address space.
randy
may have been true when the only network was ARPAnet. with the advent of Internet, if you could demonstrate runing IP you could get addresses (mostly true) remember the "connected/unconnected" database? --bill
classically, if they have no plan to be connected, they don't get address space. may have been true when the only network was ARPAnet. with the advent of Internet, if you could demonstrate runing IP you could get addresses (mostly true) remember the "connected/unconnected" database?
nope. sri internet days, netsol address days, ... even today, it says if you will be connecting to the network. it even makes sense. if you're not going to be on the internet, why the heck do you need an internet address? randy
On Sun, Jul 10, 2005 at 12:38:51PM -1000, Randy Bush wrote:
classically, if they have no plan to be connected, they don't get address space. may have been true when the only network was ARPAnet. with the advent of Internet, if you could demonstrate runing IP you could get addresses (mostly true) remember the "connected/unconnected" database?
nope. sri internet days, netsol address days, ... even today, it says if you will be connecting to the network.
true... but the "network" has changed over time. this i know becuase the commercial US defense contractor that i worked for was not able to join the ARPAnet directly (AUP issues) - we were assigned numbers from the "unconnected" database for oour global network - then the AUP changed and we were connected ... and found that the connected/unconnected databases overlapped ... my task was to renumber 134 sites. Others had similar history.
it even makes sense. if you're not going to be on the internet, why the heck do you need an internet address?
because I'm running IP-based infrastructure.... and (presuming the IPv6-enabled world) there is zero reason to treat addresses as an artifically scarce resource. Routing ... thats something else. Raw addresses - not a scarce resource.
randy
classically, if they have no plan to be connected, they don't get address space. may have been true when the only network was ARPAnet. with the advent of Internet, if you could demonstrate runing IP you could get addresses (mostly true) remember the "connected/unconnected" database? nope. sri internet days, netsol address days, ... even today, it says if you will be connecting to the network. true... but the "network" has changed over time.
so, what you actually mean is that you don't like the way things are and would like to change the status quo. that's discussable. randy
On 10 Jul 2005, at 23:38, Randy Bush wrote:
it even makes sense. if you're not going to be on the internet, why the heck do you need an internet address?
RFC1918 presents credible reasons for needing an internet address, even without a plan to connect to the Internet, and defines a number of ranges of "site-local" IPv4 addresses which may be used. RFC3879 deprecates "site-local" addresses for IPv6. I'm told that the thinking is that sites should fence off a part of their globally-routable IPv6 assignment for any "enterprise-local" requirements they may have. This leads to a significant difficulty if obtaining an address assignment is precluded by policy. As Jeroen says,
What should they do, use some random number?
2002:0a00/24 anyone? I am AGAINST this policy change until the issue of "site-local" or "enterprise-local" addressing is satisfactorily resolved. /Niall
RFC3879 deprecates "site-local" addresses for IPv6. I'm told that the thinking is that sites should fence off a part of their globally-routable IPv6 assignment for any "enterprise-local" requirements they may have.
the thinking at the time of killing site-local addresses was that, as they were specified, they had very complex and ill-thought-out routing implications (somewhat typical of the ivtf's ipv6 effort).
What should they do, use some random number? 2002:0a00/24 anyone?
if they are really not connecting, why do we or they care? if they might be connecting, then we have to make some decisions. randy
it even makes sense. if you're not going to be on the internet, why the heck do you need an internet address?
Because you are building an internetwork using the Internet Protocol. Perhaps you are connecting together several networks, some of which might also be connected to the Internet and as a result, you need globally unique addresses. If you can't imagine a "network which might be connected to the Internet" then consider a company like DeutscheBank. They have hundreds of locations connected together and one would expect that some of the sub-networks within their corporate network are rather secure because they handle millions of euros in financial transactions every day. At the same time, hundreds of DeutscheBank employees need access to the Internet through some other sub-networks. Now imagine that the financial transaction side of the business needs to connect to an IP internetwork in order to transact business with other banks and financial institutions but that this IP internetwork is not the Internet and is not connected to the Internet. There was a time when we could visualize the Internet as a nice cloud which everyone connected to. Nowadays, the picture is rather less clear as because there are many, many international IP internetworks that are not the public Internet. If you go back to that cloud picture, imagine that the millions of sites connected to the cloud form a kind of fur that surrounds the cloud. Then imagine that there are some very thin membranes that touch the tips of the fur but do not touch the cloud itself. According to RFC 2050, these membranes deserve to get registered IP addresses because they are NOT private networks. They are internetworks. --Michael Dillon
Randy Bush wrote:
These three specify a site using the upstream, which might not be necessary. There are actually sites on this planet (and maybe others ;) that need address space and are never going to connected to the Internet.
classically, if they have no plan to be connected, they don't get address space.
...and do you think this is how it should be?
randy
Wilfried
classically, if they have no plan to be connected, they don't get address space. ...and do you think this is how it should be?
in ipv4, yes. in ipv6, i am ambivalent. i don't believe v6 space is effectively so vast it can be wasted, especially with magic boundaries at /64 and /48. i also don't believe in site-local routing. though it was called site local _addressing_. the ivtf keeps confusing addressing and routing and neglecting the interactions and the implications. but i have no problem with an rfc 1918 equivalent in ipv6. on the other hand, it's can be fun to ask the question this way. since you will never be connected to the internet, why not just use whatever address space comes to mind? oh, you're worried about collisions? with whom? you said you were not connecting to the internet. randy
On Mon, Jul 11, 2005 at 07:05:40AM -1000, Randy Bush wrote:
on the other hand, it's can be fun to ask the question this way. since you will never be connected to the internet, why not just use whatever address space comes to mind? oh, you're worried about collisions? with whom? you said you were not connecting to the internet.
"extranets"... Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On Mon, Jul 11, 2005 at 07:05:40AM -1000, Randy Bush wrote:
classically, if they have no plan to be connected, they don't get address space. ...and do you think this is how it should be?
in ipv4, yes.
in ipv6, i am ambivalent. i don't believe v6 space is effectively so vast it can be wasted, especially with magic boundaries at /64 and /48. i also don't believe in site-local routing. though it was called site local _addressing_. the ivtf keeps confusing addressing and routing and neglecting the interactions and the implications. but i have no problem with an rfc 1918 equivalent in ipv6.
on the other hand, it's can be fun to ask the question this way. since you will never be connected to the internet, why not just use whatever address space comes to mind? oh, you're worried about collisions? with whom? you said you were not connecting to the internet.
randy
Never is such a long time.... --bill
Never is such a long time....
that's deep. i'll have to think about it over a second cup of morning coffee. it's not ours to judge why someone says they will never connect. but my trick question
on the other hand, it's can be fun to ask the question this way. since you will never be connected to the internet, why not just use whatever address space comes to mind? oh, you're worried about collisions? with whom? you said you were not connecting to the internet.
was designed to make them think about it about as much as we politely can. randy
Randy Bush wrote:
on the other hand, it's can be fun to ask the question this way.
since you will never be connected to the internet, why not just use whatever address space comes to mind? oh, you're worried about collisions? with whom? you said you were not connecting to the internet.
As I have in the past been involved in a couple of such requests in the past I can add the arguments as I remember they were used then: - we are going to connect to networks who are connected to other networks and some of them may be connected to the inthernet - thus the need for globaly unique adresses - we may at some future point be connected to the internet. In other works I think the definitions of "never" and of "the Internet" are important here. Maybe its better to ask are you prepared to renumber your network when you connect to another network ? -hph
At 09:04 12/07/05, Hans Petter Holen wrote:
Randy Bush wrote:
on the other hand, it's can be fun to ask the question this way.
since you will never be connected to the internet, why not just use whatever address space comes to mind? oh, you're worried about collisions? with whom? you said you were not connecting to the internet.
As I have in the past been involved in a couple of such requests in the past I can add the arguments as I remember they were used then: - we are going to connect to networks who are connected to other networks and some of them may be connected to the inthernet - thus the need for globaly unique adresses - we may at some future point be connected to the internet.
In other works I think the definitions of "never" and of "the Internet" are important here.
Maybe its better to ask are you prepared to renumber your network when you connect to another network ?
It is also useful to look at this from the perspective of convergency. If we put that to the extreme (and who knows if that is realism or not but a policy is valid for quite a while), there might in the future only be one IP network. Closed islands will then be carefully encrypted, use high grade end-to-end encryption) and advanced fire walling will do the rest (whatever). At the same time other portions are the Internet as we know it. So if we look at a potential for an extremely converged future, what does not connected mean? Today, yes, in 30 years from now, who knows? In my view it is best to do away with "private" address space concepts and plan for permanently fully de-conflicted networks. Connected or not. In my work, I see the consequences in NATO and national defence networks. I can imagine that these consequences of not using public IP space are the same if one merges 2 large cooperations and tries to integrate the infrastructures. Cheers, Marc
-hph
--------------------------------------------------------- Marc van Selm NATO C3 Agency, CISD ********************************************************* ** -- This mail is personal -- ** ** All statements in this mail are made from my own ** ** personal perspective and do not necessarily reflect ** ** my employer's opinions or policies. ** *********************************************************
actually, the american national offense network is notable for disconnecting from the internet. randy
since you will never be connected to the internet, why not just use whatever address space comes to mind? oh, you're worried about collisions? with whom? you said you were not connecting to the internet.
As I have in the past been involved in a couple of such requests in the past I can add the arguments as I remember they were used then: - we are going to connect to networks who are connected to other networks and some of them may be connected to the inthernet - thus the need for globaly unique adresses - we may at some future point be connected to the internet.
yep. expected. so please go to your nearest rir and get real address space.
Maybe its better to ask are you prepared to renumber your network when you connect to another network ?
the answer to that will always be "yes" as you did not scope 'when' randy
Hi, On Mon, Jul 11, 2005 at 07:05:40AM -1000, Randy Bush wrote:
but i have no problem with an rfc 1918 equivalent in ipv6.
The ULA approaches seem quite a nice approach to me... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
participants (8)
-
bmanning＠vacation.karoshi.com -
Daniel Roesen -
Gert Doering -
Hans Petter Holen -
Jeroen Massar -
Marc van Selm -
Michael.Dillon＠btradianz.com -
Niall O'Reilly -
Randy Bush -
Wilfried Woeber, UniVie/ACOnet