Consolidated response to this barrage:
Randy Bush wrote:
> ok, i give. if ula address space is assigned/managed by registries, how
> is it actually different from pi space?
Policy expectations. If I get PI space from a registry, the ISP I call on
knows I had to do some level of justification to get that. If I show up
trying to get a ULA space routed, they know that took no justification,
making it easier to refuse.
>
> if ipv6 space is effectively infinite (and we once thought ipv4 space
> was), then what is the use of ula address space? why not just assign
> vanilla ipv6 space?
If people could get PI everywhere, without expectation that it would ever be
routed, then your argument about equating them would hold for some uses. PI
is not globally available, and even when it is the justification is based on
need to route that much space.
>
> i am very confused by all the smoke and am trying to find the core of
> this stuff.
>
Stirring the smoke around is not helping ... There is a very basic policy
issue here, can an organization get space without being tied to a service
provider? In some areas that is possible, if one is willing to subject
themselves to scrutiny. ULA-L allows that organization to get space with a
probability of uniqueness, while ULA-C provides their management 'more
assurance' that there will not be a cost down the road related to
partnerships or m&a.
The other issue that is being mixed in is how and where filtering is done.
Yes an organization with PI space could firewall off a portion of that and
have a similar effect for some purposes. At that point you are trusting that
there are no operational errors in the firewall config over time, and that
it can keep up with the attacks. Using the ULA approach, -there is no route-
so there is less work for the firewall to do, and a very simple filter that
implemented by both the organization and the ISP.
If the need to firewall off machines does not map to subnets though, the
complexity of the firewall rules may exceed the ability of the products on
the market. This is a trade-off issue where use of ULA space alongside
either PA or PI allows the complexity to be spread out over device
management, where those that don't need external access are only accessible
using the ULA prefix.
Jeroen Massar wrote:
> > ULA space should be !A'ed out by routers per default and have a
> > special switch to enable forwarding for them.
Randy Bush wrote:
> you are asking that routers hard code the association between
> routability and address space. and next you only want this at site
> border routers and not 'internal' routers. this was called site-local,
> and was soundly rejected as
> a disaster in the making.
There is a big difference between hard-coding and default configurations.
Strict RPF is another thing that should be 'on by default'; because in both
cases the people that need it turned on are not aware they need it, while
those that need it turned off are smart enough to turn the knob (and if they
are not smart enough they probably really need it turned on).
SL was killed off due to fear mongering, not because it was it was a
disaster. There were no rational arguments, just a mob of chicken-little
screaming. There was nothing in the spec that said the bits had to be zero,
but there was also nothing in the spec that said they should not be. Rather
than fixing it by telling people to use non-zero values, the mob said 'kill
the monster because we are afraid...'.
Iljitsch van Beijnum
> It troubles me that so many people are willing to deprive others of
> something that those others consider useful just because they
> themselves don't find that thing useful.
Get used to it because some of the people on these lists are control freaks
that just want to deprive others.
Shane Kerr wrote:
> But I do not think ULA central is useful to anyone.
You are entitled to your opinion.
>
> Even if ULA central is useful, I don't think it is something the RIRs
> need to be involved in.
To avoid the perpetual arguments about ULA-C vs. PI, it would be best if
both were handled by the same organization to avoid the additional nonsense
about an end run around the process. There is also the case that only
organizations that really care would even be asking for ULA-C, and if they
care enough they would be willing to become RIR members if need be.
Additional recurring revenue for what is essentially a one-time effort
should be enough of a reason for the RIR's to be involved.
Rich Emmings wrote:
> As I mentioned earlier, one of the barriers to getting management buy in
> on
> IPv6 is the fact that the standards keep changing, and this is a good
> example. To use an analogy, the financial boys won't sign off on
> starting
> the building until they get a final floor plan. Keep rewriting the spec
> to
> try and get it 'perfect' instead of 'good enough' and it'll still be in
> redesign as the last IPv4 address goes out the door?
>
> What problem are we trying to solve here? Is it a valid concern, or are
> we
> fighting the last war and blithly ignoring what will be the real
> problems
> with IPv6. (Hint, you don't know what it is either. If it's the same
> problem, it's solved. If it's something you can think of, it's probably
> being solved. It's novel.)
The standards are not being changed here, it is policy, and policy changes
all the time. The problem in this thread is that people keep mixing various
policy arguments to justify their position on why this space is needed or
not. There are several problems at hand, and various people don't want some
of them solved. This results in the confused discussion that keeps
happening, and will keep happening until the lack of IPv4 space forces a
resolution.
Unfortunately crisis based resolutions are not well thought out, and
frequently have unintended long term consequences.
Stephen Sprunk wrote:
> You have the flawed assumption that everyone who uses RFC1918 space
> today will want/need ULA-C in the future. The vast majority of folks
> will be fine with ULA-L (or PA) space, and the target market for ULA-C
> is identical to the target market for PIv6. It will be the same number
> of orgs regardless of which type of space they request, so the debate
> comes down to why we want to put orgs on ULA-C space instead of just
> giving them PI space. If they're truly going to use it privately,
> they won't consume routing slots in the DFZ, and if they aren't they'll
> be using PIv6 anyways and won't have a need for ULA-C.
I agree that the ULA-C need will map to the PI need, though ULA-C may be a
subset. The last line though is IPv4-thinking, in that it assumes people
will only use one address range at a time. People may well use PI for their
nodes that have public access, at the same time using ULA-C for the ones
that don't to minimize the firewall rules. The only 'value' to ULA-C over
ULA-L is the assurance to management that 'this has been registered so the
risk of a required renumbering event down the road is reduced'. It really
doesn't matter if human error is greater than the probability of collision
in ULA-L, this is not a technical issue, it is strictly a feel-good that
people are willing to pay for. The RIRs should be all over customers like
this, because their demands are low and their willingness to pay is high.
Leo Bicknell wrote:
> - IPv6 space is not infinite. It's a 64-72 bit address space. That's
> right, subnets with > 256 hosts are very uncommon today, so we've
> wasted 64 bits to number 256 things. That makes the space effectively
> on the long end 72 bits.
This goes back to Iljitsch's comment: just because you don't see the need,
don't deny others the opportunity to innovate...
The original proposal for 64 bits met the design goals for IPv6 by 3 orders
of magnitude, but the routing world was concerned that there would not be
enough space for the hierarchy of providers, so the entire 64 bits was given
to them and the debate raged about how many more bits to add for the hosts.
For operational simplicity in auto-configuring hosts it was decided that
EUI-64 would be the best choice because the IEEE would run out of EUI-48's
within the life expectancy of IPv6.
Now we find the routing world arguing about 'waste' because they are just a
greedy bunch that really don't want others to have something that they think
they control, even if the can't use them. To prove the point, line this up
with the FUD about not being able to route /48's as PI space because there
are just too many of them. If there are too many /48's, what in the world
would the routing system do with more bits? This occurs in the /48-/56
discussion as well because again if there are too many /48's why do we need
to make sure end sites only get /56's. This is not about 'waste', it is all
about 'control'. The policy realm is dominated by routing types, and they
want to make sure they have control over the use of the bit space, even when
they know they couldn't possibly use it. If you really want to see waste,
allocate all the bits to routing. The world will move on to some other
technology long before we run out of even /48's, because this is not the
be-all-end-all of protocols. If the allocations allow innovation, there will
be new approaches that might even minimize the workload of the routing
world.
Paul_Vixie wrote:
> the real problems with IPv6 are those it shares with IPv4, so let's just
> call it "the real problems with IP". they've been argued forever and
> go by many names. from ppml's point of view, the right name of the
> biggest problem is "lack of EID/RID split". since we're using one
> address for both identity and location, it actually matters whether that
> address is universal or private,PI or PA, etc. as tli pointed out fairly
> early on, a solution to this problem would have added a lot more to the
> IP address system lifetime than adding more bits has added or will add.
> so, the problem isn't novel, but general recognition of the problem would
> certainly be novel.
The EID/RID split is a red-herring used to confuse those that don't
understand that ISP's operate private networks, and they want absolute
control over their networks. That is fine, they should have control over
their infrastructure. The point is that IP is an inter-network technology,
something the telco world doesn't really get (and the traditional ISPs have
forgotten during the assimilation). It has been argued that the reason the
Internet won out over the traditional telco world is exactly due to the
identity and locator being merged. This allowed a chain of organizations to
have a clean-slate view of what this packet is about; where header rewriting
techniques only provide the upstream organization's interpretation.
We have the solution to the perceived problem of each ISP wanting to write
its own interpretation of what to do with this packet. It is called MPLS. No
matter what you call it, every attempt to overwrite the end-to-end semantics
of the IPv6 header with local semantics is nothing more than a label
operation. Since it is being done just for the local network, it doesn't
belong in the inter-network header, it belongs in a lower layer that already
carries local-only network semantics.
The problem is not that the EID/RID are merged, it is that the destination
network is trying to effect policy over network providers, and the network
providers are trying to prevent them from doing that so they can control
their own network. Again, I have no problem with ISPs wanting to control
their own network, but they should be using the tool that was designed for
that rather than breaking the merged semantics that the entire existing
security model is built on.
David Williamson wrote:
> Uh, neither of those reasons undermines the solution others have
> proposed: use PI space. You can always just not announce some part (or
> all) of your space. That would make it private.
So you have a printer on the same subnet as the laptop, and the laptop needs
internet access while the printer does not. Do you explicitly list every
device that is to be allowed/blocked in the firewall; or do you overlay two
prefix ranges from the public space and try to keep straight which one has
public access to make sure the printer is in the right one? It would be much
simpler operationally to have a very different range for the local-only
devices. ULA provides that. ULA-C provides an assurance to management that
there is a human maintaining a list that says 'this space is ours so we will
not have to renumber for partnerships or m&a'.
Owen DeLong wrote:
> Um, no. It's like saying that counterfeit money is bad and we'd rather
> not create a sponsored system for printing it.
The thing that distinguishes counterfeit from 'real' is who prints it. If
the same organization does the printing it is all 'real', unless they
intentionally create bogus records (errors happen even in real things).
ULA-C has value to some organizations. If you really don't want that to be
'counterfeit' space, then take it, manage it, and make it real. Otherwise
don't be surprised when addresses that are not managed by the RIRs start
showing up in real networks.
David Williamson wrote:
> My argument, however, is that
> there's no problem solved by ULA-C that can't be solved by PI space,
> and the creation of ULA-C would entirely undermine the RIR-based PI
> system.
Exactly how does ULA-C undermine RIR-PI? RIR-PI space is managed with the
expectation that it would be publicly routable if the recipient wanted to.
ULA-C space would be managed with the expectation that it would never be
publicly routed. As long as those are managed by the same organization there
would be no cross-purpose in the allocation, and as long as being an RIR
member was the prerequisite for either, then no organization would be
motivated to use one for functions where the other was expected. If the RIRs
choose not to manage ULA-C, there will be something created to do that, so
the assurances of mixing purposes goes away and it becomes a bidding war for
the cheapest registry. The fees are for membership, not address space so
every RIR member should be allocated a PI & ULA-C block, even if they never
use them. This would take all the FUD about misuse off the table.
Edward Lewis wrote:
> What I *sense* is happening here is that the RIRs are being used to
> do an end-run around the IETF process. This 'sense' is based on
> reading the draft (and seeing that this is along the lines of site
> local), looking at the mail list archives (which lacks overwhelming
> support to promote this), and the hint that the IETF is failing to
> promote ULA (perhaps that is just from the choice of words).
Despite what the message from the chairs says, the reason it was dropped was
that RIRs perceived ULA-C was an end-run around their lack of policy on PI
(really an unstated policy of anti-PI at the time). I guess it was
politically nice to leave the inter-org dirty laundry out of it .... ULA-C
will only ever see the light of day as PI in the routing system if the
remaining RIRs refuse to create real PI. PI is required legally in some
areas, and will exist despite policy for others. ULA-C will be required by
management by many of those same organizations because it offers 'fat
finger' protection through no-routing-entry in the public network. The RIRs
need to recognize reality and create the policies that manage the space.
The IETF could take up the draft and publish an RFC, but if the RIRs don't
want to manage the space then an alternate registry gets set up. At that
point there will be a bidding war over which registry provided the most
space for the least cost and everything about the status quo will end. If
the RIRs want to avoid that situation then they need to establish a policy
that RIR members get PI & ULA-C space, even if they never intend to use it.
Tony
