>> >> If those numbers fit within reasonable guesses about sustainable
>> >> DFZ growth, no problem.
>>
>> > they don't fit, but they don't have to fit, because they're not going
>> in.
>>
>> How is this going to work? Are you assuming NATv6?
>
> no. i'm assuming that the days when the DFZ was the center of the
> internet
> are going to end some day. ad-hoc networking, neighborhood networking,
> city networking, personal networking. folks will use NATv6 or proxies or
> PI or PA when they're going through the DFZ. a lot of the time ULA-C will
> be all they need.
>
> (note, this means i think networking will flow along lines defined by
> enduser interest, feature levels, technology capabilities, and money
Let's not also forget about convenience, and pain.
Here's the main difference between unannounced PI space, and ULA-C:
ULA-C is designed to never be directly announced into the DFZ.
I've been giving considerable thought to the use cases, and in particular
what it would be like to be responsible for networks at various places
in the topologies of both strictly off-grid ("local", or multi-local),
and connected to and primarily using the DFZ ("Internet" as we think of
it for IPv4).
The interesting thing is, one person's PI is another person's PA.
By that I mean, that the difference between PI and PA, is subjective.
The assignee of a PI block, who then allocates it as PA sub-blocks, is
what differentiates PA from PI. PA exists only from the perspective of the
assignee herself.
The general idea is that the bulk of address assignments used should be,
one would expect and hope, PA, and aggregated, into large assignments
of PI blocks (ideally one per ASN) in the DFZ. The scalability of the
DFZ depends on this, in fact.
On the other hand, PA is a form of "lock-in". Renumbering is painful,
if the scope of the renumbering is large.
If a PA assignment is directly to an "end user", e.g. an enterprise,
this in theory isn't likely to be a large scope, or is at least manageable.
It is when the PA assignments are further subassigned, that the scope
becomes a significant issue, and the pain (of renumbering) grows.
For example, if a large PA block has been given out, and further assigned
to hundreds of customers (of the PA block recipient), each of which has
DNS servers "on the block", if the recipient needs to renumber, the pain
is prohibitive.
Placing the potential recipient in the position of having
to choose between PA, and a difficult-and-costly-to-obtain PI block,
is by its nature harmful to the deployment of IPv6.
And it is for this reason that I advocate reducing or eliminating
costs, and relaxing the requirements for receiving PI space.
For instance, deferring the costs of PI space until the PI block is
added into the DFZ, is one option.
And admittedly, it is the interactions of 1:1 NAT and DNS that causes most
of the problems, under any scheme for handling relocation in connectivity
to the DFZ.
If we presume that PA allocators (e.g. ISPs), in their own
mutual self-interest, regardless of what is on the other side of the link,
limit ingress traffic only to the PA block itself, then what is on the
other side isn't terribly important. (Similar to BCP-38 for IPv4)
And, accordingly, the ingress traffic could be native (the PA block itself),
or 1:1 NATv6 from ULA-C space, or 1:1 NATv6 from PI space.
In a hierarchy of PI-PA assignments, it fundamentally does not matter
whether the PA block itself is being sub-assigned, or if a separate PI
block from which 1:1 NATv6 is instead PA'd and sub-assigned.
There is definitely room for DNS having hooks for handling the 1:1 NAT
issues - and this has to do with the fact that multiple 1:1 NAT'ing can
occur over a single portion of address space.
In the absence of this, however, there are a number of tricks for working
around this, that are workable enough and scalable enough, for the short
term. The very fact that 1:1 NAT tends to be "sticky" (long-lived), and
that 1:1 NAT is deterministic, and even possible to reverse at the edges
of the DFZ.
(I think for clarity, it would be best to discuss those tricks in a
separate thread. But there are definite, concrete approaches that can be
applied, to the best of my knowledge, with currently deployed code.)
The fact that 1:1 NAT isn't strictly a two-tier technology, and that the
total amount of theoretical address space is so immense, even when used in
a particularly inefficient manner, means that doubling or tripling the
effective use (by heavy use of 1:1 NAT), is not a significant cost.
Use of 1:1 NAT keeps the DFZ to a bare minimum, while still giving all the
flexibility for back-door networking at arbitrary scale.
Still, the question of what to use for the other side of NAT is important,
at least in terms of what kinds of solutions to promote, to support in
the IETF protocol and address specifications, and in the RIR policies.
What I propose is, that PI assignment be very significantly relaxed and
promoted, for use in this case.
Why?
Because, use of ULA-C for the other side of PA NATing means that should
an organization at some point need to have multihomed connectivity, the
site would need to renumber. This is because (stating the obvious) only
PI blocks can be announced into the DFZ, and ULA-C are specifically not
allowed into the DFZ.
If, on the other hand, any organization that foresees, at any point in
time, needing to be multihomed, getting PI space early and using it,
with NATv6 into PA space (for access to the DFZ), all is good.
The fact that this scales recursively is also good. Each link in the
chain is a PA to PI mapping (NATv6). And every enterprise in the tree under
a PI in the DFZ, while having its own PI block, while it is single homed,
is still aggregated into a single PI block in the DFZ.
So, the scalability of the DFZ is still limited by growth of entities
which require their own PI block, and renumbering is accomplished by
changing, as opposed to establishing, NATv6 at the single-homed PI block's
edge (upstream towards DFZ PA block). And eventually, removing NATv6
and announcing the PI block directly into the DFZ.
So, what kind of PI blocks should be made available?
I'd suggest that anything on a nibble boundary, that suits the applicant's
needs, honestly.
Simple enterprises doing "flat" networking with autoconfiguration, might
be able to make do with a single /80, which can handle 48 bits of MAC
address autoconfiguration (basically anything ever made with a NIC).
Even complex enterprises, with autoconf stuff, are likely able to make do
with a /72 or a /64. And likewise, as appropriate, /56 and /48 all make
sense, based on need.
The corresponding PA block assignments, while sticky, aren't as fixed
as PI assignments. An entity with a sparsely used PI block, could probably
be assigned a much smaller PA block. The NAT itself, arguably, could be done
by either the upstream or downstream participant, or both - the latter,
for instance, where the first bit is zero for client-side mappings,
and one for dynamic use for anything that does not match the fixed mappings,
to prevent leakage by NAT instead of filtering.
For any large and growing organization, if the end-game of IPv6 network
growth, from single-homed to multihomed, is turning off NAT rather than
changing what block is used for NAT, the net win is obvious, I would hope.
And having this carrot to wave, in addition to the stick of "IPv4 space
is all used up", is an important way to avoid too much delay in making
the eventual move. Getting significant buy-in across the board for IPv6
should be, for all of us, a goal we are consciously pursuing.
In summary:
Having an easily available third option (beyond PA and ULA-C), is something
that I think is important to remove the impediment to migration and/or
deployment of IPv6 on a large scale (numbers of entities deploying as well
as size of entities.)
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
