[arin-ppml] ULA-C and reverse DNS
owen at delong.com
Mon Mar 22 17:50:39 EDT 2010
On Mar 22, 2010, at 1:31 PM, Michael Richardson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>>>>>> "Owen" == Owen DeLong <owen at delong.com> writes:
>>> I think that this is something to repeat multiple times.
>>> I think that a lot of people regard address space as so valuable
>>> that it would be crazy to "waste" it by having two IPs addresses
>>> on a single machine.
>>> This is where I think the notion that people will pay $$$$ to
>>> have their address space routed by ISPs. It won't happen ---
>>> getting new PA will be almost free, and getting PI address space
>>> is a nominal charge given that you have $$$$ for that bribe.
> Owen> Getting is cheap. Deploying is another matter. It is the
> Owen> desire to avoid the cost of deployment that will drive this,
> Owen> not the cost of the address space. Leo summed up one likely
> Owen> scenario rather well.
> I disagree strongly. This is not IPv4.
> Maybe some organizations prefer to bribe their ISP.
> Why is it is ARIN's business to set routing policy?
It's not. However, if people are going to present arguments claiming
something won't happen because X, then, if X is specious, I will
point that out.
> Owen> Riddle me this... When you have a Link-Local, ULA-C, and a GUA
> Owen> address, how does one decide when to originate a connection
> Owen> from the GUA and when to use the ULA-C address?
> Owen> Until you have an answer for that that does not require
> Owen> updating applications, the multiple different-capability
> Owen> addresses per interface is a nice theory that is fraught with
> Owen> operational peril.
> RFC3484 describes this:
> Default Address Selection for Internet Protocol version 6 (IPv6)
And the mechanism for maintaining this "policy table" defined in section
2.1 are still missing from any implementation I'm aware of. (No, I don't
consider rsync a scalable solution to this problem).
Leaving network stack source address selection up to the local administrator
of the host is a far from ideal solution. Basically you're passing routing policy
to the systems administrator and taking it away from the network administrator.
What is needed is a way for RA/DHCPv6 to affect this decision.
Let's look at an example, Host A with one of each (link local, ULA-C, GUA)
wants to talk to Host B with Link local+GUA on a remote network.
Rule 1 does not apply, no equal addresses.
As I read Rule 2 of the Source Address selection algorithm
proposed, UAL and GUA would both have Scope: Global.
The link local is eliminated by this rule.
Rule 3 doesn't apply in this case (neither is deprecated)
Rule 4 doesn't apply, let's not complicate the example with IP mobility.
Rule 5 doesn't help, both addresses are on the same interface.
Rule 6 Since we're assuming no changes to application, labels do not apply.
Rule 7 No temporary addresses involved, does not apply.
Rule 8 is where we hit paydirt. Because only the first 3 bits are common on the
global unicast prefix, but, the first 8 bits are common in the ULA-C prefix,
we will choose the ULA-C prefix, even though it cannot reach the
destination. -- FAIL!
Interestingly there is a second rule 2 after rule 8 which talks about scope
as preferring appropriate scope. I think this is a typo. I cannot tell whether
this should be incorporated into the rule 2 in the logical location or whether
this was an older rule 2 which was supposed to be superseded by newer
rules 2-8. My best guess is the latter to be the case.
> published Feb.2003. If you know the IETF of the early 2000s, some drafts
> took many many months to get through the queue, so this represents 10
> year old work.
> On my Linux desktop I have a configuration file /etc/gai.conf that lets
> me tweak some of the values.
Good thing, otherwise, rule 8 would screw you royally on a regular basis.
> - --
> ] He who is tired of Weird Al is tired of life! | firewalls [
> ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
> ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
> Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
> then sign the petition.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Finger me for keys
> -----END PGP SIGNATURE-----
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML