Re: Moving forward on Site-Local and Local Addressing
> On Mon, 04 Aug 2003 11:06:55 -0700, > Bob Hinden <[EMAIL PROTECTED]> said: > I would like to hear from the working group on how we should proceed. I > think the choices are: I prefer this one: > A) Deprecate Site-Local addresses independently from having an alternative > solution available. I know my vote is not consistent with what I said in the previous vote after the San Francisco meeting (attached below). Though I still have the same concern (in fact, we've already seen a "confusion"), I think it is most productive to support option A and (at least try to) move forward anyway. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] --- Begin Message --- > On Tue, 01 Apr 2003 14:37:56 -0500, > Margaret Wasserman <[EMAIL PROTECTED]> said: > Should we deprecate IPv6 site-local unicast addressing? "NO -- Do not deprecate site-local unicast addressing". - because I'm not convinced that there is a clear consensus on an alternative to site-local or that we do not need such a consensus. I'm sad I must vote for NO...I've tried to convince myself by the meeting minutes, presentation slides, discussion in this list, and some private discussion, but I failed. I've seen many candidate alternatives that at least include: - arbitrary (random) global prefix - fec0:: + random bits - free prefix allocation service I've even seen a wording nit like: - leave site-local in the spec, but make a recommendation to avoid using it. (but can't this also be interpreted as a sort of 'not deprecate site-local'?) I could not be sure if we'll be able to make a consensus on any of them (or others) quickly, if we choose "deprecating" site-local. If not, the result will just be a confusion. If we can, then I don't see why we cannot first make a consensus quickly and then deprecate site-local. I (of course) don't know the final result of this vote at this moment. But regardless of the result, I'm willing to follow it without making a further objection, and will try to make a productive contribution based on the result. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [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] --- End Message ---
RE: What to do with FEC0? [was Re: Moving forward on Site-Local and Local Addressing
> That's an interesting expectation. As co-author of the planned > deprecation draft, I'd been assuming a more classical deprecation > action, in which we would simply state the previous semantics of > FEC0::/10, state that the prefix SHOULD NOT be used, but leave it > permanently assigned by IANA. > > This would break nothing that runs today. > > What do people think? I assume that "permanently assigned to IANA" has the same semantics as "unassigned" (http://www.iana.org/assignments/ipv6-address-space). If not, what is the difference? CP 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: local addresses, 6to4 and 2002:RFC1918 [Re: Moving forward onSite-Local and Local Addressing]
> On Tue, 5 Aug 2003, Keith Moore wrote: > > > We already have alternatives > > > to site-local addresses: 6to4 addresses based on PI or RFC1918 > > > IPv4 addresses. > > > > 6to4 addresses based on RFC 1918 addresses should be forbidden. > > IMHO, this is an oversight in the 6to4 RFC. > > They are already forbidden (but perhaps you're saying the forbidding > should be even stronger than it's today). yes, I'm saying that we should make it entirely clear that use of RFC 1918 addresses within 6to4 addresses are a violation of the standard, and that hosts should block them. let's stamp out scoped addresses in our lifetime. 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: Fourth alternative [was Re: Moving forward ....]
Ralph, Thanks for the clarification. I think I misunderstood "not replace site-local addresses in any form". If I have it right, the phrase implies "explicitly do not consider any alternatives", to which I agree that accepting indicates that the WG is interested in considering alternatives. That is correct. Also, any specific alternative will have to go through the normal w.g. and IETF processes so it's not done until the RFC is published. Thanks, Bob 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: state-of-art SLs
> humm - it is not all that often that we have said that 2/3 is rough > consensus in the IETF note that the plurality was 3/4 not 2/3. 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: Fourth alternative [was Re: Moving forward ....]
Christian, It is possible to write sufficient restrictions and avoid both the drift towards announcing /48 in the DMZ and using the unique local addresses in a NATv6 configuration. The requirement is that the site local replacement be "special". We can for example request that backbone routers ignore announces that fall in the special prefix unless a /48 has been explicitly. As a result, even if someone convinces their local ISP, they will not be able to get connectivity to the whole Internet, and the addresses will not be usable as "globally routed PI." In fact, we should do that. I agree, and it is already in the draft. The current draft includes text on this in two places. In section 4.0 "Routing": Any routing protocol that is used between sites is required to filter out any incoming or outgoing Local IPv6 unicast routes. The exception to this is if specific /48 IPv6 local unicast routes have been configured to allow for inter-site communication. If BGP is being used at the site border with an ISP, by default filters MUST be installed in the BGP configuration to keep any Local IPv6 address prefixes from being advertised outside of the site or for these prefixes to be learned from another site. The exception to this is if there are specific /48 routes created for one or more Local IPv6 prefixes. and in section 6.0 "Site Border Router and Firewall Filtering": While no serious harm will be done if packets with these addresses are sent outside of a site via a default route, it is recommended that they be filtered to keep any packets with Local IPv6 destination addresses from leaking outside of the site and to keep any site prefixes from being advertised outside of their site. Site border routers SHOULD install a black hole route for the Local IPv6 prefix FC00::/7. This will insure that packets with Local IPv6 destination addresses will not be forwarded outside of the site via a default route. Site border routers and firewalls SHOULD NOT forward any packets with Local IPv6 source or destination addresses outside of the site unless they have been explicitly configured with routing information about other Local IPv6 prefixes. The default behavior of these devices SHOULD be to filter them. Is this sufficient? Would it better to also include an "operational considerations" or similar section? More text on why this is important? Bob 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 to do with FEC0? [was Re: Moving forward on Site-Local andLocal Addressing
> > That's an interesting expectation. As co-author of the planned > > deprecation draft, I'd been assuming a more classical deprecation > > action, in which we would simply state the previous semantics of > > FEC0::/10, state that the prefix SHOULD NOT be used, but leave it > > permanently assigned by IANA. > > The term "permanent" is a bit long. It should not be used for some > period of time, and since there's a lot of address space out there, > perhaps that period of time should be considerable ;-) I don't think we're so short of address space that we'll miss it. Mark that address block as deprecated, and make it take an IETF Consensus process to reallocate it for some other purpose. 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: Fourth alternative [was Re: Moving forward ....]
Interesting point. Feel free to look up 192.102.91.0. It is being NAT'ed for a client of mine. I've not convinced them yet to route it with a real firewall to their isp ;-( -- Todd Fries .. [EMAIL PROTECTED] Free Daemon Consulting, LLCLand: 405-748-4596 http://FreeDaemonConsulting.com Mobile: 405-203-6124 "..in support of free software solutions." Key fingerprint: 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A Key: http://todd.fries.net/pgp.txt (last updated 2003/03/13 07:14:10) Penned by Michel Py on Tue, Aug 05, 2003 at 11:26:32AM -0700, we have: | Eliot, | | > Eliot Lear wrote: | > I guess my concern is that ISPs end up routing the address | > space in Bob's proposal and that we'll have another PI problem. | > So while there's nothing wrong with Bob's proposal in theory | > (indeed I prefer it vastly to the other SL approaches), if | > customers believe they have stable addresses we could end up | > right back where we were in the early '90s. I don't see this | > happening for DSL customers but it could happenfor medium to | > large size businesses who have the power of the purse. | | I raised this very issue a long time ago, but that is not the worst | problem we have. Finish the reasoning down that same path: | | - Sites will get unaggregatable portable /48s. | - Their wallet will get them routed. | - Everyone is happy, no renumbering issues, multihoming is possible. | | So, everyone will spend 5 bucks registering their /48, some (the ones | that currently have an AS or will request one) will actually announce | it, and we're all fat and happy. Until the GRT reaches 10k (and probably | until it reaches 50k by the time that happens given better hardware) it | won't be a concern. | | What happens next is more interesting. Re-using some wording I have read | yesterday, this will become a self-regulating system, meaning that only | those who can afford it will be able to announce their /48 after some | time. | | The question is: in 5 or 10 years, what are these people that are | running production networks configured with addresses that they own | going to do when they can't announce their prefix anymore? Bingo, | welcome to NATv6. | | Replacing site-locals with NATv6. Think about it. | | Michel. | | | | 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] | 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: Moving forward on Site-Local and Local Addressing
> We already have alternatives > to site-local addresses: 6to4 addresses based on PI or RFC1918 > IPv4 addresses. 6to4 addresses based on RFC 1918 addresses should be forbidden. IMHO, this is an oversight in the 6to4 RFC. 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: state-of-art SLs
> The chances that SL addresses will simply be deprecated are something > approaching zero. SLs are a virus that must be eradicated at any cost. the best available method is quarantine. routers need to start filtering SLs by default. apps need to refuse to use them. DNS servers need to refuse to advertise them. gethostinfo needs to put them last. host stacks need to ignore RAs that include SL prefixes, and to use SLs only as a last resort. 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: Moving forward on Site-Local and Local Addressing
Sorry; yes I have read that draft and plan to comment on it. My remarks had to do with the "Choice A" approach of removing SLs without advancing that draft (or something else) _at the same time_. --On Tuesday, August 05, 2003 10:00 -0700 Fred Templin <[EMAIL PROTECTED]> wrote: Hans Kruse wrote: There is real danger here; I have already started to see mailing list discussion going something like: Q. What address prefix do I use for this network before I get my provider prefix? A1. Use FECO (Site Local). A2. No, No, FECO has been outlawed by the IETF, just invent a prefix! I have seen the 2002 mapping of RFC 1918 suggested. "Private" space will appear -- I want a version that is thought out, that is well documented and understood, not a mish-mash of hijacked prefixes and IPv6'afied RFC1918 stuff. Perhaps you havn't seen 'draft-hinden-ipv6-global-local-addr-02.txt'? Fred [EMAIL PROTECTED] Hans Kruse, Associate Professor J. Warren McClure School of Communication Systems Management Adjunct Associate Professor of Electrical Engineering and Computer Science Ohio University, Athens, OH, 45701 740-593-4891 voice, 740-593-4889 fax 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: Fourth alternative [was Re: Moving forward ....]
> What this means to me is that first we need to promulgate something > along the lines of draft-baker-ipv6-renumber-procedure-00.txt. It > needs some expanding to further automate the process. The more we > automate the less pain the network manager will feel during a > renumbering event. I concur. A real story for renumbering is probably the biggest "missing piece" of the IPv6 puzzle, and we need to be devoting our energies to solving this important problem rather than to propagating past errors. 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 to do with FEC0? [was Re: Moving forward on Site-Local andLocal Addressing
Brian E Carpenter wrote: That's an interesting expectation. As co-author of the planned deprecation draft, I'd been assuming a more classical deprecation action, in which we would simply state the previous semantics of FEC0::/10, state that the prefix SHOULD NOT be used, but leave it permanently assigned by IANA. This would break nothing that runs today. What do people think? Maybe just list it as "IANA - Reserverd" for now? There are a number of prefixes in the current IPv4 address space listed in exactly this manner. See: http://www.iana.org/assignments/ipv4-address-space Fred [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: Fourth alternative [was Re: Moving forward ....]
Brian E Carpenter wrote: Eliot, That seems to me to be orthogonal. I agree that it would be good to see renumbering support (maybe it's a v6ops item??). But that doesn't destroy the value of Bob's proposal. I guess my concern is that ISPs end up routing the address space in Bob's proposal and that we'll have another PI problem. So while there's nothing wrong with Bob's proposal in theory (indeed I prefer it vastly to the other SL approaches), if customers believe they have stable addresses we could end up right back where we were in the early '90s. I don't see this happening for DSL customers but it could happenfor medium to large size businesses who have the power of the purse. Eliot 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: Site-Local and Local Addressing -- "Replacement" Choices
This may be a nit -- but wouldn't it make more sense then to call you preferred course of action "B", and publish 2002:RFC1918 as the (temporary) replacement? I guess I am suggesting that the WG pursue its work in such a way that we do not create a vacuum; I feel strongly that the set of IPv6 standards documents should clearly define the address space to use for the cases that folks have suggested are currently covered by site-local. --On Tuesday, August 05, 2003 16:07 +0100 Zefram <[EMAIL PROTECTED]> wrote: The three options are really the same. We already have alternatives to site-local addresses: 6to4 addresses based on PI or RFC1918 IPv4 addresses. We didn't have these alternatives a few years ago. These aren't perfect, which is why we must develop draft-hinden-ipv6-global-local-addr, but they're enough that fec0::/10 seems rather unnecessary in any current IPv6 deployment. They particularly handle the requirements of those organisations that want site-locals because that's what they had with IPv4 and they want the same again. So I support option A, deprecate site-locals independent of further development of alternatives. We have sufficiently good stopgap solutions. I'm expecting, by the way, that the deprecation will leave fec0::/10 to be treated as global-scope unicast addresses, rather than making fec0::/10 addresses cease to function altogether. -zefram 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] Hans Kruse, Associate Professor J. Warren McClure School of Communication Systems Management Adjunct Associate Professor of Electrical Engineering and Computer Science Ohio University, Athens, OH, 45701 740-593-4891 voice, 740-593-4889 fax 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: Moving forward on Site-Local and Local Addressing
The three options are really the same. We already have alternatives to site-local addresses: 6to4 addresses based on PI or RFC1918 IPv4 addresses. We didn't have these alternatives a few years ago. These aren't perfect, which is why we must develop draft-hinden-ipv6-global-local-addr, but they're enough that fec0::/10 seems rather unnecessary in any current IPv6 deployment. They particularly handle the requirements of those organisations that want site-locals because that's what they had with IPv4 and they want the same again. So I support option A, deprecate site-locals independent of further development of alternatives. We have sufficiently good stopgap solutions. I'm expecting, by the way, that the deprecation will leave fec0::/10 to be treated as global-scope unicast addresses, rather than making fec0::/10 addresses cease to function altogether. -zefram 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: Moving forward on Site-Local and Local Addressing
I vote for B from individual technical perspective. C and A can only be agreed with politically. - Original Message - From: "Bob Hinden" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, August 05, 2003 3:06 AM Subject: Moving forward on Site-Local and Local Addressing > [IPv6 working group chair hat on] > > I think the working group has been making good progress on replacing > site-local addresses and wanted to get feed back from the working group on > how we should move forward. This is not intended to directly relate to the > ongoing appeal of the working groups decision to deprecate the usage > site-local addresses, but to get feedback on how to proceed. I think it is > very important that we move forward on this issue and not rehash what has > happened in the past. > > We now have a combined local addressing requirements document > , a specific alternative to > site-local addresses draft > (accepted as a working group item at the Vienna IETF), and will soon have a > draft describing why site-local addresses are being deprecated and doing > the formal deprecation (authors identified and outline discussed at the > Vienna IETF). Note that all of these documents will proceed through the > normal working group and IETF processes of last calls and review. > > I think legitimate questions have been raised about how the working group > should go about deprecating site-local addresses given their maturity in > the current specifications and use in deployed products. Specifically > should they be deprecated independently from having an alternative solution > available, at the same time an alternative is available, or sometime after > an alternative is available. A forth alternative is to not replace > site-local addresses in any form, but I think the working group has made it > clear that this is not a reasonable alternative. > > I would like to hear from the working group on how we should proceed. I > think the choices are: > > A) Deprecate Site-Local addresses independently from having an alternative > solution available. This would mean that the working group should treat > the deprecation, and requirements and solution documents outlined above > independently from each other. If there was no consensus on an alternative > a replacement would not happen. > > B) Deprecate Site-Local addresses at the same time as a alternative > solution is agreed to. This would mean advancing both documents at the > same time and making them include normative references to each other to > insure that they were published at the same time. This would result in the > deprecation only happening if a consensus was reached on an alternative. > > C) Deprecate Site-Local addresses after an alternative is defined, > standardized, and in operational practice. This would mean not advancing a > deprecation document until there was operational evidence that the > alternative was working and shown to be an improvement over Site-Local > addresses. > > Note: In the above choices "Deprecate Site-Local addresses" means > publishing an RFC that does the formal deprecation. > > Please respond to the list with your preference, or if there is an > alternative approach that is an improvement from the ones I outlined. I > hope that many of you will respond. > > Thanks, > Bob > > > 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] > > 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: Moving forward on Site-Local and Local Addressing
Jeroen, > Jeroen Massar wrote: > At this moment you can announce almost anything > you want apparently. Yep I see /32 /33 /35 /40 /41 /42 /44 /48 /64 from some peers, Including some interesting ones such as: 2001:530:DEAD:BEAD::/64 This is the very reason we have to be very careful with any kind of globally unique address that has a global scope, because it can really quickly degenerate into having clueless ISPs that don't care to clueful salespersons that see an opportunity. As a few thousand prefixes would not be a problem at the beginning, it might take of really quick leaving a big mess to clean up some years later. > Fortunatly there are clued ISP's who do > filter accordingly to: > http://www.space.net/~gert/RIPE/ipv6-filters.html NRENS do filter too for what I have seen. > As you are probably one of the many people who really > knows that we need is: Multihoming ;) How did you guess that? Michel. 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]
Fourth alternative [was Re: Moving forward ....]
Ralph, Furthermore, based on the record of the question from the minutes of the SF meeting and the question put to the ipng mailing list, how was this conclusion arrived at: A fourth alternative is to not replace site-local addresses in any form, but I think the working group has made it clear that this is not a reasonable alternative. It's from my reading of the discussion (on the mailing list and in the meetings) and the fact that the working group decided to accept as a working group document in Vienna. Bob 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: Fourth alternative [was Re: Moving forward ....]
Bob, I am sorry, but while it is a good attempt to come up with a happy medium between SLs and global addresses, I disagree with the approach that draft-hinden-ipv6-global-local-addr-02.txt takes. I would prefer an approach that makes the stability of the IP address less important rather than attempting to stablize it (a seemingly lost cause). What this means to me is that first we need to promulgate something along the lines of draft-baker-ipv6-renumber-procedure-00.txt. It needs some expanding to further automate the process. The more we automate the less pain the network manager will feel during a renumbering event. This changes the problem from one of a scoped address to one of a standard default and reduces any ambiguity that we might have. It leaves open the question of how to find a name server, and how a name server finds you, but the former can be found with SLP, and the latter can then be handled with DDNS. I'd like to put Fred on the spot (not having asked him) and propose that his draft be adopted as a WG doc. Eliot 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: Moving forward on Site-Local and Local Addressing
Patrik Fältström wrote: From an Application (above TCP) perspective, A, definitely A. Itojun summarizes well the issues. Mandating a host to know topology is just a really bad thing. Really really bad. I concur with an added "really" tagged on. 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]
