Re: Taking two steps back (Was: Re: one question...)
> From: Keith Moore <[EMAIL PROTECTED]> > Subject: Re: Taking two steps back (Was: Re: one question...) > Date: Tue, 26 Nov 2002 15:29:52 -0500 > > > The lack of global routability of site-local addresses is a > > feature, not a bug. > > I don't think we have concensus on that. there seem to be at least > a few people who want PI addresses that *are* routable, or at least, > for which such restrictions are not imposed. IPv4 has globally routable GUPI (GRUPI) addresses. That's all it had in the early days. The explosion in the size of the routing tables is was forced changes such as CIDR and new addresses being allocated from ISP blocks. The only reason we still have GRUPI addresses in IPv4 is because they were grandfathered in. With the current routing structure, trying to define IPv6 GRUPI addresses is doomed to failure because it will not scale. We learned that with IPv4. Until there is a new routing structure that will support scaling of GRUPI addresses, we should not define GRUPI addresses. We are talking about 3 different classes of addresses, they should each have their own block of address space: 1) Leave FEC0::/10 as Site Local addresses. They are not globally unique, but several proposals have been proposed for picking them in a somewhat random method to make them mostly unique. Site Locals should be free and not require any registration. 2) There seems to be a need for a globally unique version of Site Local addresses (GUSL), so we should just define a new block for them. These would require registration, and perhaps a fee, just like when you get a domain name. 3) If anyone ever comes up with a method for handling the problem of scaling GRUPI addresses in the routing protocols, then at that time we can define a third block for GRUPI addresses. At the Atlanta IETF meeting I voted for limited use of Site Local addresses. That is because we have several issues for dealing with SLs, DNS support being one of the top items. It seems to me that the pros and cons of SL vs. GUSL vs. GRUPI have been discussed in great detail, and we now just seem to be rehashing the same things. 1) We seem to have a better handle on dealing with GUSL addresses (or at least we've identified issues that SLs have that can be mitigated by having GUSL addresses), so we should get a block of address space reserved for GUSL addresses, and those who want them can work on getting the registration rules set up. 2) Many of the issues that GUSL addresses mitigate can be mitigated for SLs by having random generation of SL prefixes. So we should select the method(s) of generating pseud-random SLs and document it (them). 3) We should list the specific problems that will occur with wide-spread deployment of SLs and GUSLs, and start to work on them one at a time. 4) The people who really want GRUPI addresses should work on the scaling issues with routing, and if that is ever solved then a new block of addresses can be allocated for GRUPI. -David Borman IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Taking two steps back (Was: Re: one question...)
> From: Keith Moore <[EMAIL PROTECTED]> > Subject: Re: Taking two steps back (Was: Re: one question...) > Date: Mon, 02 Dec 2002 10:48:43 -0500 > > > 2) There seems to be a need for a globally unique version of Site Local > >addresses (GUSL), so we should just define a new block for them. > >These would require registration, and perhaps a fee, just like when > >you get a domain name. > > I think it's still up in the air as to whether these are really local > to a site in the sense that site-locals were assumed to be. In other > words, can they be routed between sites by private agreement? Sure, why not? I don't think we can stop it from happening. And I don't see anything inherently wrong with it. The problem with trying to globally route PI addresses is the routing table explosion it causes to the global internet. If a site wants to route SLs or GUPI addresses with another site over a private link, then they are just bloating their own routing tables (but probably not enough bloat to cause serious problems). I see 3 options: 1) State that PI addresses (SL, GUSL/GUPI, GRUPI) are not routeable between sites, even over private links. 2) State that PI addresses (SL, GUSL/GUPI, GRUPI) are only routeable between sites over private links. 3) State the PI addresses are not routeable over the global internet. I don't think that stating #1 is going to prevent #2, so I'd vote for #3. As long as people don't impact the global internet, how they choose to configure private links is up to them. > > 4) The people who really want GRUPI addresses should work on the scaling > > issues with routing, and if that is ever solved then a new block of > > addresses can be allocated for GRUPI. > > or they can just start routing GUPIs. Yes, but as others have pointed out, if there are filters everywhere to block them it might be easier to create a new block for GRUPI addresses than trying to "upgrade" the GUPI addresses. -David Borman IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: "unique enough" [RE: globally unique site local addresses]
> Date: Mon, 09 Dec 2002 09:50:04 -0500 > From: Margaret Wasserman <[EMAIL PROTECTED]> > Subject: Re: "unique enough" [RE: globally unique site local addresses] ... > I have the following things running around in my brain, and they aren't > converging: > > - We need to provide PI addressing in IPv6, or we will > see wide deployment of IPv6 NAT in enterprises > and homes. No one seems to be disagreeing with > this. > > - We think that the use of NAT is one of the serious > architectural problems facing the Internet today, > and that NAT is blocking the advancement of the > Internet in many ways. For an IPv6 Internet to > be a "success", we must avoid the wide-scale > deployment of IPv6 NAT. By themselves, GRUPI addresses might prevent NAT6. But currently we can't handle the scaling issues with GRUPI addressess in the global routing structure, so that's a non-starter. And non-globablly-routable PI addresses won't by themselves prevent NAT6 (see below). ... > So, where do we go from here? 1) We define a block for allocating GUPI addresses, and figure out how they will be allocated. 2) We define methods for allocating Site Local prefixes, possibly splitting up the SL address space into different blocks for different scenarios. I'm not convinced of the absolute need for GUPI addresses, since they are not going to be globally routable. But they do simplify some edge cases of merging/moving networks, make it easier to identify the offender when they leak into the global internet, and they might be a bit easier to deal with (than SL) in DNS. So, I don't have any objection to them. At the same time: 3) Start listing the issues with using local addressing on networks that are connected to the global internet (either GUPI or SL, the issues should the same), and then work to solve those issues. These are things like the DNS issues, and private routing between consenting sites. I think that preventing NAT6 is a big challenge. Neither SL nor GUPI addresses do anything to help us there. In fact, I think that GUPI addresses have the potential to justification of NAT6 worse. To properly run run an IPv6 network with global connectivity and with SL and/or GUPI addresses, each machine will need to be configured with at least two addresses. If it is perceived that this is difficult to do or not the proper way to do things (don't we keep discouraging running dual IPv4 networks over the same wire?), then I could see network administrators opting to use the private addresses on their networks, and using NAT6 to provide the global connectivity. And if you've *sold* them a guaranteed unique block of private address space (as opposed to them picking a SL network), I'd see them feeling even more justified in using that block. So, I don't think that providing GUPI addresses alone will do anything to prevent the use of NAT6. What will prevent NAT6 is to make sure that it is simple and easy to configure both globally routable and SL/GUPI addresses on the same network, and address the problems caused by having that configuration. Also anything to provide education about how using a firewall to protect your network is vastly superior to thinking that NAT provides security would be helpful. And lastly: 4) At this time, do not allocate globally routable/unique provider independent (GRUPI) addresses. The routing issues *have* to be figured out first. Once that happens, then I'm all for GRUPI addresses. But until there is some hope that the scaling issues can be overcome, we'd best not even start down that path. As for how far and wide SL/GUPI addresses should be used, I don't think we need to answer that up front. I think it really depends on how well we can address the issues caused by having them on networks connected to the global internet. The less we have solved, the more they should be restricted. -David Borman IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: CONSENSUS CALL: Deprecating Site-Local Addressing
Hi, I was at the meeting in SF, and I was one of the minority that voted to not deprecate site-local addresses. Well, if I am allowed to, I am now changing my vote to: "YES -- Deprecate site-local unicast addressing". Perhaps folks might be interested to know why I originally voted NO, and why I am now changing my vote. If not, you can stop reading now. :-) Many people who have been voting NO have been including the list of possible reasons that Bob and Margaret put in the message: > Possible reasons include: > > - Site-locals should be retained for disconnected sites. > - Site-locals should be retained for intermittently > connected sites. > - Site-locals should be retained for their access control > benefits. > - Site-locals should be retained as a means for internal > connections to survive global prefix renumbering. ... Aside from the access control benefits, these are some of reasons why I originally voted NO. These are important issues, and they should be addressed. I don't want to see them ignored. I voted NO not so much that I felt that Site-locals were the solution to all these problems, but that I felt that Site-locals helped to keep a spotlight on these issues. My fear was that if we deprecated Site-locals, then people would decide that we don't need to worry about these issues any more. Deprecating site-locals doesn't get rid of these issues, it just removes one possible solution (and not necessarily a good solution) to them. So, there are issues and problems with Site-locals. (If there weren't we wouldn't even be having this discussion!) After seeing all the discussion on the list for the past week, I've come to the conclusion that rather than Site-locals keeping a spotlight on these issues so that they will get solved, they have become a stumbling block that is delaying those issues from being solved. The spotlight is on Site-locals themselves, not the issues that need to be solved. There are other approaches than Site-locals to addressing the above problems. I have a proposal that I'm working on writing up to directly address the disconnected/intermittently connected site issue. (And if you solve that, you probably get the internal connections surviving global prefix renumbering for free.) But I don't have it written up to a point where I could distribute it as an internet draft. I've verbally discussed it with a couple of people, but I have some more issues that I need to work through to decide for myself whether or not it is feasible. So that's what I think we should do. Deprecate Site-Locals as they are defined today (which isn't much of a definition), and then focus on solving these problems without the having the burden of being forced to cram the solution into Site-local addresses. -David Borman, Wind River Systems PS: I view claiming Site-Locals for access control benefits on par with "security through obscurity". If you want access control, put in real access control. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: what is a site?
> From: "Joris Dobbelsteen" <[EMAIL PROTECTED]> > Subject: RE: what is a site? > Date: Thu, 29 Mar 2001 16:43:03 +0200 > > >-Original Message- > >[mailto:[EMAIL PROTECTED]]On Behalf Of Tomohide Nagashima > >Sent: Wednesday, 28 March 2001 9:52 > >Subject: Re: what is a site? ... > >At least, it is clear that "Site" is a set of links. But is > >the subset of Site > >the Site ? ... > >I begin to believe this answer is YES.If else, what > >do we call that ? > >I belive this will be a key of definition of "Site". > > So a site can be hierarchical and can a site also be a part of two (totally) > different sites? > Wouldn't this get quite messy... >From the definition of a site-local address in RFC 2373, pg. 10: Site-Local addresses have the following format: | 10 | | bits| 38 bits | 16 bits | 64 bits| +--+-+---++ |111011|0| subnet ID | interface ID | +--+-+---++ Site-Local addresses are designed to be used for addressing inside of a site without the need for a global prefix. Routers must not forward any packets with site-local source or destination addresses outside of the site. The address format does not currently allow for hierarchical "site-local" addressing. Just as a machine can be attached to more than one link, with a link-local address on each link, a machine can be attached to more than one site, and thus have a site-local address in each site. The machine has to keep track of what site-local addressess are associated with each site, just as it has to keep track of which link-local addresses are associated with each link. I would expect that the machine would have a (logical) interface for each site to which it is attached. So, one definition of a "site" might be a collection of machines and networks that are all interconnected and accessable via the same set of site-local addresses (ignoring administrative barriers...). You could have a "site within a site", but it wouldn't be a sub-site. The transition points into and out of the "sub-site" would block all site-local addresses from crossing the boundry. So, what you really have is two sites, and what it looks like just depends on how you draw the picture. If the desire was to allow Big Sites to encompass multiple Small Sites, then we'd have to change the addressing format, say: | 10 | | bits| 38 bits | 16 bits | 64 bits| +--+-+---++ |111011| Site ID| subnet ID | interface ID | +--+-+---++ But if a host was to be part of both the big and the small site, it would have to have a site-local address for each site. So, I guess this would be more to allow overlapping sites, as opposed to sub-sites. It just seems like a sub-site when the bigger site totally overlaps the smaller site. But the "Site ID" would still not be guaranteed unique, a machine could still be attached to two Sites that each have the same Site ID. And with the addition of a "Site ID", you'd give people a whole lot more rope to build an administrative nightmare of overlapping sites. Maybe we better first figure out how to use the currently defined site-local addresses before delving into adding a "Site ID"... -David Borman, [EMAIL PROTECTED] IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: RFC 2553 bind semantics harms the way to AF independence
In seems to me that all this discussion about what the default
behavior should be when binding to a wildcarded AF_INET6 socket
doesn't address the issue: deterministic behavior for portable
application across multiple operating systems.
And just to lay my cards on the table, I support the current
default behavior of having AF_INET6 sockets receive both IPv4 and
IPv6 packets.
Isn't the real problem that we have added an IPV6_V6ONLY option,
but not an IPV6_V4ANDV6 option?. If we add that, then portable
applications can explictly state what actions they want, and they
don't have to worry about OS defaults. The success and failure
cases are then obvious and well defined:
bind#1 AF_INET6 w/IPV6_ONLY
bind#2 AF_INET6 - fail
bind#2 AF_INET4 - succeed
bind#1 AF_INET6 w/IPV6_V4ANDV6
bind#2 AF_INET6 - fail
bind#2 AF_INET4 - fail
bind#1 AF_INET4
bind#2 AF_INET6 w/IPV6_ONLY - succeed
bind#2 AF_INET6 w/IPV6_V4ANDV6 - fail
Thus, you have deterministic behavior. And that's the end goal
for portable applications, isn't it?
-David Borman, [EMAIL PROTECTED]
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
