[ppml] a modified proposal 2005-8

[Tony Hain]

(Howard, W. Lee & bmanning below)
Michael.Dillon wrote:
>
> >From a policy point of view, we must remember that the
> IPv6 address space is finite. At the same time it is intended
> to be very big so that it is very hard to use up all of the
> space. Any scheme which maps some locator, like GPS coordinates,
> directly onto the IPv6 address space, is likely to result in
> large amounts of unusable address space due to the fact that
> most territory on the earth is covered by ocean or uninhabited
> wilderness. Therefore, the only politically tenable scheme
> would be one that uses a database. 

This presumption is still open for political debate. Yes there will be some
waste. The question becomes 'is that waste worth the value it returns in
terms of simplicity and isolation from long term political squabbles?'. If
you choose a strict database model you are presuming that there is still
some organization that has rights and authority to decide who gets how much.
At the same time the implication is that the organization remains as it is
today. An alternate outcome might be that the RIR community casts the
'control' model followed by a take over by the UN/ITU who could then say 'we
didn't define it'. 

> In fact, this type of
> scheme is proven to work for interactive applications since
> this is how phone number portability works.

While that model works for service provider controlled applications, it
would be more effort to implement for P2P application models. The timeliness
of global database updates would have to be better than dns, and there is
always the 'trust' issue about who has access and rights to make the change.
The problem of crossing the trust boundary should not be minimized.

> 
> Given that such mapping schemes are almost certain to
> be based on a database, then there should be no scaling
> problems.

Then why does it take so long for simple dns changes to propagate globally?
Wouldn't that be due to an operational requirement specifically implemented
to deal with scale? After all DNS is a distributed database. Or are you
assuming that this is a central database which has scaling issues in another
dimension? There are always scaling problems; it is just a matter of finding
the lowest cost trade-off. 

> 
> Security issues are another thing. Even if you propose
> some sort of address translation scheme that maps a homeowner's
> /64 onto the house's /64, this does not automatically allow
> either the homeowner or the house to use an arbitrary range.
> The power company who wishes to monitor and control home electrical
> systems (presumably in return for a better rate) will want to
> implement layers of security. One of those layers is a globally
> unique IPv6 address range. Another layer is a entirely separate
> physical path from the house for this address range. Inside
> devices we can expect that the homeowner's /48 will touch the
> same interfaces as the power company's /64, but the device itself
> will have some strict routing controls to prevent exchange of
> packets between the two network. The extent of the mixing is
> unlikely to go beyond allowing the homeowner some visibility of
> monitoring data and some ability to override settings (if they
> will accept loss of their discount during the override period).

There are many opportunities for different models than are currently in use.
Presuming that isolation or uniqueness are required is based on current
practice rather than what might make technical sense in any specific
deployment. MIPv6 with IPsec/AES protection on the data would provide the
logical isolation necessary for the utility provider, while at the same time
allowing a 4193 based address to be routed via the home network public
range. A different model would be a fixed firewall configuration only
allowing inbound connections from pre-defined addresses to specific
appliances. Both or neither might be considered 'secure' depending on who is
defining the meaning of 'security'. The bottom line though is that presuming
the world will continue with a PA-only for the home model 'just because the
service provider wants it that way' is likely to lead to revolt and
political requirements to fix the problem. 

> 
> If all of this sounds too pie in the sky for you, then we
> have a failure of imagination. This is a bad thing considering
> how the developers of IPv6 were already talking about an IPv6
> address for every lightbulb and light switch over 10 years ago.

For reference look at:
http://panasonic.co.jp/corp/news/official.data/data.dir/en060105-2/en060105-
2.html
This is not just imagination, appliance vendors will be network enabling a
vast array of non-traditional devices. 


Howard, W. Lee wrote:

> Just because one changes does not mean the others need to change.
> That's why we have DNS and logical pointers.  The stack isn't
> monolithic.  There are several network protocols that can
> accomodate this requirement, but TCP/IP isn't designed that way.

It isn't -operated- that way. The only requirement for IP addresses to
change comes from the desire to minimize cost in the routers. 

In any case, Terry's point is that the same kinds of 'technical' arguments
were made before LNP was mandated. Note the politicians didn't care and
required the technical community to get over it. If you put a hard stake in
the ground about PA for consumers it is likely the same result will occur.
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 changed providers at home four times in the last two years.
> My personal web site and my personal email address have been
> unaffected.  I reduced my DNS TTLs, made the DNS change, and cranked
> the TTLs back up.  I run my own server, but it would have been as
> easy if I'd been hosted.

Obviously you run with static addresses. While there are ddns services out
there, it is still not trivial for the average consumer to make this work.
As long as DNS as a system is built and operated in 'guru's only' mode,
there is no hope that it can be used to mask over the mandatory change you
advocate by PA-only. 

> 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. 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. If you
want to do 'simple' reverse dns delegation and management then nibble
boundaries are called for. Finally if the operator of the network wants
isolation then more subnets are required. 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. 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. 

> ...
> 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. 

> Remote participation is also an option.

Doesn't always work well. 



bmanning wrote:

> One of the
> 	current difficulties of the RIR system is that it is designed
> 	to be bottom-up, consensus-driven when it comes to address
> 	assignment policies.  That type of methodology works very well
> 	for a well established modality - is very hard to try radical
> 	new ideas ...  but ARIN seems to be more responsive in this regard
> 	than many RIR/LIRs..  perhaps not responsive enough for some. :)

This actually hits the mark dead on. To a first order the RIR community
needs to get over the fact that we will waste IPv6 space. This is directly
counter to their stated goals as stewards, but is a reality no matter how
well the space is managed. Even with current policies we will see a
replacement due to other technology changes long before the 500 years that
the proposed HD ratio change will provide (assuming we have defined a
protocol to last for all time is just a bit arrogant). The balance is that
the goal needs to be 'make it possible to run several hundred years', rather
than 'make sure we don't waste any along the way'. 

We can define geo models for stable PI that will have different waste
characteristics. The 'control' minded will prefer city-code or rir/area
approaches where they can maintain a level of power. The fixed-allocation
approach will have a clearly identifiable waste in space (at least for
today's perception of habitability), while it removes the continuous 'wasted
energy' of political control/pushback. The current PA-biased policy favors
control, while the end sites are wasting energy pushing back to demand
independence through PI. The 'give a little but reserve the right to refuse'
middle ground is just looking for a point where power is retained while only
acquiescing to the equally powerful end sites. 

The open question is how one defines waste?
Tony