From: ietf-bounces@xxxxxxxx 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf