[ppml] a modified proposal 2005-8

[Tony Hain]

Howard, W. Lee wrote:
> ...
> > It isn't -operated- that way. The only requirement for IP addresses to
> > change comes from the desire to minimize cost in the routers.
> 
> That's a couple of logical steps from my statement, but I see how you
> get there.  I would still say that layer 3 changes don't necessarily
> require layer 7 changes, which is why we have a layered model.

The layering design means it is not 'necessary' for upper layers to know the
details below, but for a variety of reasons application programmers believe
they need to violate the layers. 

> 
> > If you appear to be working toward a middle ground that
> > provides a level of
> > stability to the home user without the scaling problems inherent in a
> > database model, then the politicians will likely back off and
> > give you a chance.
> 
> I've heard two home users say they don't like having to change IP
> addresses when they change ISPs.  One of them said they didn't like
> it because they had to change email addresses and web addresses, and
> I'm not convinced those are all related.  Should ARIN conduct a poll
> of random homeowners to see if IP address portability is a common
> concern?

A survey would not hurt, but it might not help much either. Most politicians
are less clueful than their constituents and would equate IP address changes
with phone number changes because they are represented in numerical form.
You can argue all day that the name string solves the problem, but to the
non-technical a number is a number. 

> ...
> There are multiple ways to skin this cat, and permanent assignment
> of provider-independent is one.  Is it the best one?  To evaluate
> "best," it's important to understand the implications.

Yes, and it is important to realize that 'best' is relative to ones
viewpoint. PA pushes the costs to the edge. Clearly best for the core
operators, but no so for the edge operators. PI does the inverse. In IPv4
you were effectively forced to choose one or the other. Multi-homed sites
essentially required, and end users had a bias toward PI because they did
not want to deal with renumbering when changing providers. In the IPv6
design multiple simultaneous prefixes were added to help mitigate the
renumbering and some of the multi-homing issues. For some organizations the
multiple prefix approach is still insufficient to deal with their
multi-homing cases, so we still need to provide PI. Defining PI in a way
that avoids overwhelming routing and minimizes the need for
justification/detailed-analysis is the current challenge.

> 
> I've backed off my PA-only stance.  As a board member, I try not to
> advocate for or against policy, but I do try to make sure I
> understand what other people are advocating for or against.

I am not keeping tabs on who is taking what stance. If I appeared to be
making a case that you were personally taking a position I apologize because
I didn't mean to. I was trying to stay aware and avoid the use of the
collective use of the word 'you' because it could be misinterpreted as a
directed personal sense, but it appears I screwed up in the discussion about
finding a middle ground. 

> 
> 
> > > We're still talking about residences, right?
> > ...
> > > Do these three networks need one /64, three /64s, or one /62?
> >
> > I know the context changed in the original note, but it
> > applies to both the
> > home and plane cases. The answer is that it depends on the
> > goals of the end
> > network operator, and the mix of technologies in use.
> > Multi-media bridging
> > is just a broken concept and history is full of failed
> > attempts.
> 
> I don't know what that means.  Is that bridging as I understand
> it in the Ethernet world, applied to multiple layer 2 protocols?

Yes. While it appears to be a simple design to strip off one L2 header and
replace it with another, the actual semantics of differing media types make
the resulting frames non-compliant in some way or another. There has been a
fairly long running convergence on 'ethernet' as a framing technology,
simply to deal with this problem. Unfortunately media semantics have
suffered as a result (ie: 802.11 is less than optimal for what they might
have had with a clean slate for design). We are rapidly approaching the
point where the cost of maintaining compatibility will outweigh the risk of
starting fresh, as the overhead and limitations at 10G already show. 

There will be new media types in the home over the life of IPv6. IP over
1394 may not have done much, but something in the space of consumer media
will come up with an optimization that has non-ethernet framing, and will
need IPv6 to work over it. This is where the layering design provides value.


> 
> You offer three sets of policy spaces:
> 1.
> > Unless you restrict all future networks to use today's link-layer
> > 'ethernet' technology
> > then the answer has to be they always need more than a single
> > /64.
> 
> 2.
> > If you
> > want to do 'simple' reverse dns delegation and management then nibble
> > boundaries are called for.
> 
> 3.
> > Finally if the operator of the network wants
> > isolation then more subnets are required.
> 
> With #1 and #2, should the home be assigned a /62?  /48?

2 argues that it should be /44, /48, /52, /56, or /60. 

> Then each network gets a separate /64 slice? 

Each media type, or other reason for a separate subnet would get a /64 from
that list. 

> I'm having trouble
> understanding the routing, unless it's a separate route entry for every
> house /64.  Or /48.
> Or does each network assign its own /64?  This is the current policy.

In the PA case there is a protocol called DHCP-PD which is designed to allow
the provider to allocate a prefix block to the customer. Assuming the
assigned block is shorter than a /64 the customer then uses whatever method
locally to manage the set of /64's in the block. The service provider has a
single route to the assigned block, but that route should be from an
aggregate assigned to the pop so the explicit routes for a collection of
homes is only known where they attach. If the customer is multi-homed to
that provider, with the appropriate agreements the customer might announce
back more specifics along with the aggregate from each attachment point. The
world outside that provider should only need to know the aggregating prefix
though. 

In the PI case the prefix lengths would be the same to minimize managing
subnet design, but the route would not aggregate under the provider pop. A
totally random (sequential first-come) assignment scheme assures there will
never be aggregation of those PI prefixes. A regional assignment scheme
starts to allow the thought of aggregation, but requires sufficient
foresight to draw the boundaries in line with future demands. City based
schemes go further in terms of optimizing aggregates with current need, but
will be challenged by population shifts over time. The approach I have been
looking at is flexible about where aggregates are applied, vs. where they
are not worth the effort, so it can evolve to meet current need at any
point. 

Any of the aggregation schemes will require different business models than
the current free-for-all approach. The carriers know how to do structured
interconnection in the PSTN space; to know how and where to route the detail
below the aggregates. That structure will need to be developed before the
uptake of any aggregating PI approach finds widespread use. 

> 
> > Why should ARIN or a service
> > provider get to decide if their 'want' justifies more than a
> > single /64, or /60? The IPv4 space was limited and needed oversight.
> In IPv6
> > a degree of
> > oversight is appropriate, but there are diminishing returns
> > to consider.
> 
> What level of oversight do you suggest?

The IAB recommendation at /48 was partially intended to minimize any
oversight to only the vary rare cases where that could be clearly shown to
be insufficient. A /56 default would keep most SOHO users at bay, but might
end up with a lot of work for the medium and large businesses. 

> On what grounds would it be appropriate to deny a request for additional
> 
> IPv6 address space?

This is the hard question, because there is a subtle difference between
stewardship and a policing action (fairness vs. power). Clearly one needs to
be able to say no, or everyone will fall into the ego driven 'mine is
bigger' mode until it is all gone. At the same time there is a cost to
evaluating requests, both in developing and reviewing, so blanket
requirements for review impedes utility while it increases the staffing
demands of the reviewer. 

As Manning pointed out, the case-by-case evaluation in the context of
today's norm makes it hard to deal with new ideas. Larger than currently
necessary defaults allows for new deployment concepts without strict
oversight that might prematurely cut them off. 

The thing is that none of this actually answers your question about what
defines a valid reason to say no. I have gone around on this point a few
times and every time it strengthens my bias toward approaches that minimize
the need to even consider the question. This logically leads to 'give
everyone PI, no questions asked'. While that is a fine thing to say, it
leads to 'how much', and 'what about routing'? 'How much' should be dealt
with in a way that doesn't required detailed evaluation; equal amounts
aligned with something existing, non-controversial, and trivial to measure.
Dealing with routing requires the ability to abstract out the pockets where
uptake is causing a table size problem and the remote network doesn't
perceive a difference anyway. 

Once you get to this point it is just a matter of which optimization makes
the most economic sense. I happen to prefer an optimization that precludes
any political influence, and is insulated from population shifts over time.
It has a well documented 'waste of space' in terms of today's population
distribution. No approach will be perfect, as they will be the result of
engineering/policy trade-offs (the 'designed by committee' problem).
Whatever we do will be perceived to be the least cost/risk path at the time,
and will be questioned a generation down the road when all the issues are
long forgotten.

> 
> > It
> > would be very easy to waste the majority of the IPv6 space by
> > refusing to
> > let people have as much as they would use thereby driving
> > them to find a
> > replacement sooner than they will otherwise. When it never
> > gets used due to
> > replacement it is just as wasted as if it gets handed out in
> > too large a block and remains idle.
> 
> Well said.
> 
> 
> > > ...
> > > Is the passenger laptop on board supposed to use an aircraft IP
> > > address, or its home address?
> >
> > The answer is yes, depending on the specific application. If
> > the app is
> > onboard entertainment it should use an address from the
> > aircraft. If the
> > application is VoIP then it should use its home address so
> > inbound calls can
> > find it. Fortunately IPv6 allows for both to exist at once.
> > The alternative
> > would be a single address & ddns system that was globally
> > responsive enough
> > to deal with the update rate, not to mention one that
> > actually trusted the
> > endpoint to make changes as it moved around.
> 
> How does that phone call find you, if you're still using your home
> prefix?  We're still in that endpoint-network identifier spin.  I
> don't say it can't, I'm asking for education.

Mipv6 would be a dynamic way to handle the problem, while a vpn would be a
more nailed up approach. Both would use the aircraft address for bit
delivery, but the application would be working in terms of the home address.
Layer violation? Yes. Requirement to satisfy app developers? Also yes.

> 
> > > Remote participation is also an option.
> >
> > Doesn't always work well.
> 
> I agree it's not as good as being there, but it's participation,
> and it's an option.
> 
> > The open question is how one defines waste?
> 
> Goals:
> IPv6 for a hundred years or so.
> Do not outpace routing.

Don't forget, allows for new concepts to move beyond past limitations.

Tony