[arin-ppml] ULA-C and reverse DNS

[Owen DeLong]

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

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

Owen

> - -- 
> ]       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
> 
> iQEVAwUBS6fTsYCLcPvd0N1lAQLnEQf/YPYIhS5xWhClPcggfyeRdrdzYwVF3Bq0
> V5rv+TAq4bJu8EDo8YkDrQpaDSuIEoDH5d83wJGRrt03d33umBs97mxzFXSOgWjN
> 7FkUwh7JZ7hVCImkGnrsuWvXPIKgt2200ytC6OhXh6ThMQ9eC5ucfudjmX0+jgRx
> rh4lpkY9k4lvt3Ezxi7nYJoZICiQ3PM1v0zydJKzcdULkZw6NElqj6JP9qBuJ+ug
> RtZUmQf8JePhGCRhViMWrzWnQ0IXoFHencWLh9AY3XKWcA8/vArld7QD3MX76xPx
> uI5+IJFe1GSVuLd4DErJAYkTqdvQ/P+O84rwvZm7aTXqaBYHdfAM5w==
> =tf0L
> -----END PGP SIGNATURE-----
> _______________________________________________
> PPML
> 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:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.