Re: 240/4 unreservation (was RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)
On 27 Sep 2011, at 5:45 , Christian Huitema wrote: if an address space is somehow set aside, we have no mechanism to enforce that only ISP use it. So we have to assume it will be used by whoever feels like it. How is that different from the current situation? Is there a reason why potential users of 240/4 will refrain from that use because it's called class E but not if it's called ISP private? And who cares anyway? If people feel it's a good idea to use addresses in the 240/4 block, more power to them. That saves more usable addresses for other uses. It is also important to avoid mistakes during the transition period from IPv4 to IPv6. I understand that many actors are anxious and waiting for some kind of fix. This is a common scenario for making substantial mistakes... Agree. We have to make absolutely sure that all the hacks that are going to be implemented to stretch IPv4 don't find their way into the IPv6 world. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 240/4 unreservation (was RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)
From: ietf-boun...@ietf.org On Behalf Of Iljitsch van Beijnum And who cares anyway? If people feel it's a good idea to use addresses in the 240/4 block, more power to them. That saves more usable addresses for other uses. WEG] The problem is that people really can't today, because vendors mostly do not want to implement something for general consumption that is deliberately out of compliance with one or more RFCs. My point in asking the question was that I'm not sure that we need to define what use cases it can/should be used for as much as we simply need to unreserve it and provide some guidance about risks. IMO, the question tree on determining what (if any) course of action to take is something like this: 1) should it be unreserved for *any* reason, or are we just going to stick with the 5735 status quo (Future use)? 2) should it be made into more global unicast space in all or in part? 3) should it be simply unreserved as non-global space with a few caveats about limitations, and leave the use cases to the consenting adults considering its use? 4) should it have a designated use(s) to the exclusion of all not explicitly defined? For #1, My view is that there's no good reason to maintain the reservation, because then essentially no one can use it, and the likelihood of someone coming up with a use for it that justifies holding it in reserve for future use continues to drop. So it's more a question of how we might use the space, and the justification for doing any one of several things. I don't agree that the burden of proof should favor doing nothing. For #2, We know that it is not trivial to get it working for this purpose due to the critical mass of support required. But in some cases where there is tight control over equipment and networks, and a community of interest that routinely communicates between one another across a portion of the Internet, perhaps it's possible. I'm thinking that this makes more sense as a means to buy us time to get IPv6 deployments completed if CGN ends up being bad and the demand for global IPv4 space gets high enough that any tradeoffs associated with using this space as global unicast are deemed acceptable. It may be that we carve the space up so that some of it is tentatively reserved for global unicast, but not released to IANA until some later point to give folks time to fix things. I agree that this one has a lot of risk that it ends up simply prolonging IPv4 without aiding the transition to IPv6. For #3, it's mainly about the caveats to its use - it may not be supported by legacy equipment, we have to carve out 255.255.255.255 (or perhaps something between 255/8 and 255.255.255/24) for broadcast, it MUST NOT show up in the global routing table, etc For #4 - I'm not sure we can come up with enough designated uses at the outset to not have to continue evaluating new ones all of the time and end up needing a WG just to keep up with the discussion. So far, we've heard about its use within a mobile provider in place of RFC1918 as Mobile UE addresses behind a CGN that's already in place today. The folks wanting a shared CGN address pool have already turned down 240/4 because of the limited support within the legacy home router CPE gear. What other potential uses are there? 1918 space in enterprises where all of 1918 is already in use (eg mergers, extranets, etc)? I think Iljitsch's point is a good one - why do we care how people use it? As long as we can give them some guidance about how *not* to use it in order to avoid breakage, I think we're doing our jobs. Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 240/4 unreservation (was RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)
On Sep 26, 2011, at 10:07 AM, George, Wes wrote: From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Keith Moore Sent: Friday, September 23, 2011 10:04 PM To: Cameron Byrne Cc: IETF Discussion Subject: Re: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC On Sep 23, 2011, at 9:53 PM, Cameron Byrne wrote: So if there is going to be breakage, and folks are willing to fix it over time because the good outweighs the bad (I personally do not believe this), then why not dedicate 240/4 for this purpose? The 240/4 work has been shot down multiple times ( I don't know the history ), are we now changing the rules for the end run ? It's hard to know for sure, but I believe there's greater risk associated with use of 240/4 than with a /10 from existing public IPv4 space. That is, I think more software would be needed to allow 240/4 to be used reliably. WEG] you know, the more I think about this line of logic, the more I wonder about it. In essence, the 240/4 problem is that lots of host and router implementations have one or more functions in their input validation code that says “240/4 == invalid” thus preventing you from configuring or using it. To my (admittedly oversimplified) view, this is a simple matter of: 1) Search source code for “240” 2) Comment out any relevant code you find 3) Recompile, test (changes only), ship I’d be happy for one or more folks who have some experience with the appropriate bits of Windows, Linux, MacOS, IOS, JunOS source code would explain where I’m oversimplifying. I think that's basically right. The problem isn't in the difficulty of finding these changes and fixing them, for currently maintained code. The problem is in the zillions of systems in the field that have assumptions about 240/4 wired into them, most of which either have no automatic upgrade mechanism, aren't set up to use it, or aren't being maintained. This is of course, in addition to any changes that have to be made to application software because of its wired-in assumptions about 240/4. By contrast, if a /10 from public unicast IPv4 address space is used, only the application software has to be changed (if the application software needs to care about whether an address is ambiguous). That's a much smaller impact, though probably still a significant one. Actually it wouldn't bother me personally if the /10 were specified only for use with DS-Lite or with some other service that provided native v6 prefixes to customers in addition to any IPv4 service...though I don't know of any way to enforce that. I’m willing to write a draft about it if there are people willing to support it, but I only have so many windmills that I can tilt at per cycle, so I’d like to hear support either privately or publicly before I undertake it. Honestly I'd guess that if vendors started changing their code today, it would be 10 years before 240/4 could be widely used in the field. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 240/4 unreservation (was RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)
On 26 Sep 2011, at 18:41 , Keith Moore wrote: The problem isn't in the difficulty of finding these changes and fixing them, for currently maintained code. The problem is in the zillions of systems in the field that have assumptions about 240/4 wired into them, most of which either have no automatic upgrade mechanism, aren't set up to use it, or aren't being maintained. This is the traditional problem with using 240/4, but it doesn't really apply in this specific case, because those addresses will only be touched by the CGNs in the ISP network, the routers in the ISP network and the home gateways. So especially in the case where NAT444 is only used for new customers this may not be an issue at all. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 240/4 unreservation (was RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)
On Sep 26, 2011, at 12:47 PM, Iljitsch van Beijnum wrote: On 26 Sep 2011, at 18:41 , Keith Moore wrote: The problem isn't in the difficulty of finding these changes and fixing them, for currently maintained code. The problem is in the zillions of systems in the field that have assumptions about 240/4 wired into them, most of which either have no automatic upgrade mechanism, aren't set up to use it, or aren't being maintained. This is the traditional problem with using 240/4, but it doesn't really apply in this specific case, because those addresses will only be touched by the CGNs in the ISP network, the routers in the ISP network and the home gateways. and the home gateways _never_ expose their external addresses to internal hosts or applications?not even via NAT-PMP or UPnP? (are they really home gateways in all cases?) seems to me that if you're an ISP and have the luxury of upgrading all of the CPEs, that's a very compelling case for DS-Lite instead of relying on more v4 address space kludges. but of course the devil is in the details. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 240/4 unreservation (was RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)
On Mon, Sep 26, 2011 at 9:41 AM, Keith Moore mo...@network-heretics.com wrote:
On Sep 26, 2011, at 10:07 AM, George, Wes wrote:
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf
Of Keith Moore
Sent: Friday, September 23, 2011 10:04 PM
To: Cameron Byrne
Cc: IETF Discussion
Subject: Re: Last Call: draft-weil-shared-transition-space-request-03.txt
(IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
On Sep 23, 2011, at 9:53 PM, Cameron Byrne wrote:
So if there is going to be breakage, and folks are willing to fix it over
time because the good outweighs the bad (I personally do not believe this),
then why not dedicate 240/4 for this purpose? The 240/4 work has been shot
down multiple times ( I don't know the history ), are we now changing the
rules for the end run ?
It's hard to know for sure, but I believe there's greater risk associated
with use of 240/4 than with a /10 from existing public IPv4 space. That is,
I think more software would be needed to allow 240/4 to be used reliably.
WEG] you know, the more I think about this line of logic, the more I wonder
about it.
In essence, the 240/4 problem is that lots of host and router
implementations have one or more functions in their input validation code
that says “240/4 == invalid” thus preventing you from configuring or using
it. To my (admittedly oversimplified) view, this is a simple matter of:
1) Search source code for “240”
2) Comment out any relevant code you find
3) Recompile, test (changes only), ship
I’d be happy for one or more folks who have some experience with the
appropriate bits of Windows, Linux, MacOS, IOS, JunOS source code would
explain where I’m oversimplifying.
I think that's basically right. The problem isn't in the difficulty of
finding these changes and fixing them, for currently maintained code. The
problem is in the zillions of systems in the field that have assumptions
about 240/4 wired into them, most of which either have no automatic upgrade
mechanism, aren't set up to use it, or aren't being maintained. This is
of course, in addition to any changes that have to be made to application
software because of its wired-in assumptions about 240/4. By contrast, if a
/10 from public unicast IPv4 address space is used, only the application
software has to be changed (if the application software needs to care about
whether an address is ambiguous). That's a much smaller impact, though
probably still a significant one.
Actually it wouldn't bother me personally if the /10 were specified only for
use with DS-Lite or with some other service that provided native v6 prefixes
to customers in addition to any IPv4 service...though I don't know of any
way to enforce that.
This is the 2nd time DS-lite has come up, this comment is off topic,
but i want to make sure the inputs are right.
DS-lite would not use this space and does not need this space, DS-lite
assumes the following: RFC1918 + IPv6 public in the end-site (my home)
with a B4 tunneling home gateway, IPv6-access network (DSL/Cable
access network), and public routable space in the CGN/AFTR.
DS private IPv4 LAN -{IPv6 only access network} CGN Internet
draft-weil space is only for what draft-weil says it is for, and that
is the NAT4'4'4, the middle 4 SP access network or to facilitate
6to4-PMT (NAT66 of 6to4).
IPv4 LAN ---IPv4 access with shared space CGN --- Internet
IMHO, this allocation does not move IPv6 forward... it just makes
NAT444 more possible and fixes 6to4 so that the IPv6 part returns to
the correct IPv4 NAT network.
DS-lite does move IPv6 forward.
But, AFAIK, the draft-weil folks want a /10 so that they don't have to
spend money to upgrade their access network or associated CPE. In
this way, end points that need real unique IPv4 space are subsidizing
the upgrade deferral of these networks.
Cameron
I’m willing to write a draft about it if there are people willing to support
it, but I only have so many windmills that I can tilt at per cycle, so I’d
like to hear support either privately or publicly before I undertake it.
Honestly I'd guess that if vendors started changing their code today, it
would be 10 years before 240/4 could be widely used in the field.
Keith
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: 240/4 unreservation (was RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)
Regardless of the ease of implementing the change (which is quite simple in the linux case for example), the question is really what is the impact on existing systems? The presumption is they won't change until they age out of the network which is the same reason any a+p solution that requires host signalling or new private scope unicast ranges have negative implications for the support of legacy systems. By that measure 240/4 is unequivically not useful (for this purpose). It was also not useful 4 years ago (for this purpose). On 9/26/11 07:07 , George, Wes wrote: *From:*ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] *On Behalf Of *Keith Moore *Sent:* Friday, September 23, 2011 10:04 PM *To:* Cameron Byrne *Cc:* IETF Discussion *Subject:* Re: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC On Sep 23, 2011, at 9:53 PM, Cameron Byrne wrote: So if there is going to be breakage, and folks are willing to fix it over time because the good outweighs the bad (I personally do not believe this), then why not dedicate 240/4 for this purpose?The 240/4 work has been shot down multiple times ( I don't know the history ), are we now changing the rules for the end run ? It's hard to know for sure, but I believe there's greater risk associated with use of 240/4 than with a /10 from existing public IPv4 space. That is, I think more software would be needed to allow 240/4 to be used reliably. WEG] you know, the more I think about this line of logic, the more I wonder about it. In essence, the 240/4 problem is that lots of host and router implementations have one or more functions in their input validation code that says “240/4 == invalid” thus preventing you from configuring or using it. To my (admittedly oversimplified) view, this is a simple matter of: 1) Search source code for “240” 2) Comment out any relevant code you find 3) Recompile, test (changes only), ship I’d be happy for one or more folks who have some experience with the appropriate bits of Windows, Linux, MacOS, IOS, JunOS source code would explain where I’m oversimplifying. Now, compare that with the discussion of adding a new set of non-unique address space where you likely have to add code to catch this if you care about the scope of the address that you’ve been assigned. The authors (or at least one of them) of draft-bdgks maintain that they’ve discussed this with vendors (http://www.ietf.org/mail-archive/web/opsawg/current/msg01879.html, search for Linksys to find the relevant section of the message) and the vendors seem willing to make code changes in support of this, at least in new gear. Now this doesn’t represent a commitment nor a critical mass necessarily, but I’m wondering why 240/4 is so much harder? Also, I don’t see why we don’t use all of the tools in our toolkit. We’re out of IANA space, except for a whole /4, which keeps getting shot down due to the perceived problems with getting global support, when there are probably multiple use cases that absolutely don’t require global support. Why haven’t we gone ahead and unreserved the space, and then let those interested in using it beat on the appropriate folks to fix it, rather than not even trying? I think that it would be fully possible to caveat use of the space appropriately so that people know what the risks are, but right now it’s essentially useless even for those who might be able to try. Seems wasteful, no? I’m willing to write a draft about it if there are people willing to support it, but I only have so many windmills that I can tilt at per cycle, so I’d like to hear support either privately or publicly before I undertake it. Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 240/4 unreservation (was RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)
From: ietf-boun...@ietf.orgmailto:ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Keith Moore Sent: Friday, September 23, 2011 10:04 PM The problem is in the zillions of systems in the field that have assumptions about 240/4 wired into them, most of which either have no automatic upgrade mechanism, aren't set up to use it, or aren't being maintained. snip Honestly I'd guess that if vendors started changing their code today, it would be 10 years before 240/4 could be widely used in the field. WEG] See that's the point, I think we keep looking at this from a boil the ocean perspective. The question is not, could we use 240/4 as more global unicast space? as the ship sailed on that years ago when IETF apparently decided it was too hard to change and nothing should be done. The question is, if the space were unreserved, are there valid use cases where networks within a given administrative control might be able to make use of it? This idea of limited use puts the impetus on the network/operator itself to identify a use case and force their vendors to confirm support for the space, but it makes it more likely that for that definition of widely used it would be successful. But if IETF/IANA removes the reservation, this means means that people can go in and check in the update to the 3 lines of BSD kernel code (based on a private reply I received on the matter) necessary to remove the block, vendors can stop putting that logic into new devices, etc, thus making it more attractive to attempt to use the space from that point forward. I don't expect this to be a perfect solution for legacy IPv4-only devices, but I do expect that it could have some use, especially when compared with other alternatives. Cameron's example is a case in point - you have a mobile provider who for the most part tells the vendors exactly what features their user devices need to support and they are built to spec, plus a closed network with NAT at the edges that is currently squatting on public space. This means that a large amount (or possibly all) of the devices that would need to support use of this space are within their administrative control, and they would be responsible for updating the code to a version that won't reject 240/4, and they could contain it within their environment by keeping it inside of the NAT border. Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 240/4 unreservation (was RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)
On Sep 26, 2011, at 2:15 PM, George, Wes wrote: From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Keith Moore Sent: Friday, September 23, 2011 10:04 PM The problem is in the zillions of systems in the field that have assumptions about 240/4 wired into them, most of which either have no automatic upgrade mechanism, aren't set up to use it, or aren't being maintained. snip Honestly I'd guess that if vendors started changing their code today, it would be 10 years before 240/4 could be widely used in the field. WEG] See that’s the point, I think we keep looking at this from a “boil the ocean” perspective. The question is not, “could we use 240/4 as more global unicast space?” as the ship sailed on that years ago when IETF apparently decided it was too hard to change and nothing should be done. The question is, “if the space were unreserved, are there valid use cases where networks within a given administrative control might be able to make use of it?” maybe. But I personally don't believe that such addresses won't leak out. I'd say if a network operator wants to make a case for it using 240/4, it can write up an Internet-Draft detailing how it would be used along with containment measures, and petition IETF to ask IANA to permit such use. The last thing that's needed is to open up that space for general use for anybody who thinks it's a good idea. And I sympathize with the notion that any use of the precious remaining reserved v4 space should somehow credibly promote IPv6 adoption. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 240/4 unreservation (was RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)
On 26 September 2011 16:07, George, Wes wrote: I’m willing to write a draft about it if there are people willing to support it, but I only have so many windmills that I can tilt at per cycle, so I’d like to hear support either privately or publicly before I undertake it. Maybe the IETF could agree that it won't use the former class E for any past, present, or future experiments. Updating RFC 1112 (STD 5) or maybe RFC 1166, and then RFC 5735 for 6.25% of all windmills minus one. -Frank http://omniplex.blogspot.com//2008/06/lost-found-268435455-free-ips.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 240/4 unreservation (was RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)
I will be a bit more direct than Keith. There is no such thing as no leakage. These addresses will leak, no matter how well you believe you are isolated. Indeed, the issues posed by similar leakage were one of the main argument developed in RFC 3879, Deprecating Site Local Addresses. We see here a proposal to create site local IPv4 addresses for Internet providers. The IETF previously expanded significant efforts to deprecate IPv6 site local addresses. Why exactly do we believe that IPv4 site local addresses would be a good idea, when the consensus was that IPv6 site local addresses caused more harm than good? From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Keith Moore Sent: Monday, September 26, 2011 1:16 PM To: George, Wes Cc: IETF Discussion Subject: Re: 240/4 unreservation (was RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC) On Sep 26, 2011, at 2:15 PM, George, Wes wrote: From: ietf-boun...@ietf.orgmailto:ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org]mailto:[mailto:ietf-boun...@ietf.org] On Behalf Of Keith Moore Sent: Friday, September 23, 2011 10:04 PM The problem is in the zillions of systems in the field that have assumptions about 240/4 wired into them, most of which either have no automatic upgrade mechanism, aren't set up to use it, or aren't being maintained. snip Honestly I'd guess that if vendors started changing their code today, it would be 10 years before 240/4 could be widely used in the field. WEG] See that's the point, I think we keep looking at this from a boil the ocean perspective. The question is not, could we use 240/4 as more global unicast space? as the ship sailed on that years ago when IETF apparently decided it was too hard to change and nothing should be done. The question is, if the space were unreserved, are there valid use cases where networks within a given administrative control might be able to make use of it? maybe. But I personally don't believe that such addresses won't leak out. I'd say if a network operator wants to make a case for it using 240/4, it can write up an Internet-Draft detailing how it would be used along with containment measures, and petition IETF to ask IANA to permit such use. The last thing that's needed is to open up that space for general use for anybody who thinks it's a good idea. And I sympathize with the notion that any use of the precious remaining reserved v4 space should somehow credibly promote IPv6 adoption. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 240/4 unreservation (was RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)
Frank Ellermann wrote: Maybe the IETF could agree that it won't use the former class E for any past, present, or future experiments. Updating RFC 1112 (STD 5) or maybe RFC 1166, and then RFC 5735 for 6.25% of all windmills minus one. Given that NAT can expand the space 100 or 1000 times, while maintaining the end to end transparency if you so wish, it's not 6.25% but 625% or 6250%. That is, unreservation is worth doing and as the first step, it is a good idea to use some of the space for shared transition where all the equipments having the unreserved addresses should be able to treat the unreservation. However, as the unreserved space is still precious, only small part of the space should be allocated for shared transition. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 240/4 unreservation (was RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)
Frank Ellermann wrote: Oops, I failed to send the following to the list. Updating RFC 1112 (STD 5) or maybe RFC 1166, and then RFC 5735 for 6.25% of all windmills minus one. Updating RFC1112 is not necessary because, even though it says: *a datagram whose source address does not define a single host -- e.g., a zero address, a loopback address, a broadcast address, a multicast address, or a Class E address. Class E is an example and, more interestingly, the rule is silently ignored by ICMPs generated against private use addresses, which do not define single hosts. Updating RFC can be as simple as follows: 240.0.0.0/4 - This block, formerly known as the Class E address space [RFC1112], and was reserved for future use [RFC5735] is now allocated for use in IPv4 unicast address assignments with default netmask of 0x. The addresses in the block is not special use IPv4 addresses anymore. There are two exceptions to this. One exception is the limited broadcast destination address 255.255.255.255. As described in [RFC0919] and [RFC0922], packets with this destination address are not forwarded at the IP layer. Another exception is the shared transition block of 240.0.0.0/12, which is set aside for use in private ISP (not end user) networks. Its intended use is to be documented in a future RFC, As will be described in that RFC, addresses within this block do not legitimately appear on the public Internet. These addresses can be used without any coordination with IANA or an Internet registry. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 240/4 unreservation (was RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)
On Sep 26, 2011, at 6:21 PM, Christian Huitema wrote: We see here a proposal to create site local IPv4 addresses for Internet providers. The IETF previously expanded significant efforts to deprecate IPv6 site local addresses. Why exactly do we believe that IPv4 site local addresses would be a good idea, when the consensus was that IPv6 site local addresses caused more harm than good? Not exactly to play devil's advocate here, but I don't think these are quite like site-locals. It seems like they're more like ISP locals. One of the problems with site locals was that they were ambiguous addresses AND that they would need to be used by applications, and we had plenty of experience that said that RFC 1918 addresses caused harm.If 240/4 wouldn't be used or seen by applications at all, the fact that those addresses would be reused in other networks wouldn't be such an issue. Though I agree that these will leak, even if they're never used as application endpoints. If one of them ever appears as a source address on an ICMP reply, for instance, that actually will cause problems - perhaps not problems that directly affect applications, but problems nonetheless. (Then again, tunnel use is now quite widespread, which means that packets travel paths that are completely invisible to the endpoints and look like a single hop to them.And there are of course problems with those, but we sort of deal with them.) Another of the problems with site locals was that there was no clear boundary that corresponded to a site, so why have a special class of addresses for a site? If that's also true for an ISP, maybe an ISP local address isn't such a good idea either. What happens if two ISPs that are each using 240/4, merge? Probably the same kind of mess you get when two enterprises that use RFC 1918 addresses merge. Granted, ISPs might not merge as often as enterprises, but still... It was especially important to get rid of site locals in IPv6 because IPv6 was in very early stages of deployment, and any errors in its design would be magnified over time. By contrast, IPv4 is a dinosaur struggling to take its last unassisted breaths, and which is starting to be put on life support. Some sort of extraordinary measures to keep IPv4 vlable for a short time might be in order, even if those measures would never make sense in IPv6. So my take is that using 240/4 is not an absolute no. But that bit of address space is a very precious resource and there needs to be strong justification for using it, along with reasonable assurance that it will not do significant harm in relation to the amount of benefit it will likely provide. And merely prolonging the life of IPv4 is probably not sufficient justification. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 240/4 unreservation (was RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)
Not exactly to play devil's advocate here, but I don't think these are quite like site-locals. It seems like they're more like ISP locals. I know that is the proposition. But if an address space is somehow set aside, we have no mechanism to enforce that only ISP use it. So we have to assume it will be used by whoever feels like it. It was especially important to get rid of site locals in IPv6 because IPv6 was in very early stages of deployment, and any errors in its design would be magnified over time. It is also important to avoid mistakes during the transition period from IPv4 to IPv6. I understand that many actors are anxious and waiting for some kind of fix. This is a common scenario for making substantial mistakes... -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
