From: ietf-bounces(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf