<massive snip>
Actually, gethostbyname returns a linked-list and applications should
try everything in the list until successfully connecting. Most do.
However, the long timeouts in the connection attempt process make
that a less than ideal solution. (In fact, this is one of the main =
reasons
that Google does not publish AAAA records generally today).
However, that isn't the issue above. The issue above is about whether
or not:
getaddrinfo() always returns the addresses to be tried in proper
order.
Applications are always well behaved in attempting connections
in the order returned by getaddrinfo()
Whether the deployment of the gal.conf file to hosts in order to
give getaddrlinfo() the correct hints about ordering is
likely to occur correctly and reliably.
etc.
There are many dependencies to making source address selection
in IPv6 work correctly. They are exacerbated in a ULA environment.
If you thought putting a single address (or prefix) into a CPE router
by hand was hard, do you really expect the customer to manage
a gal.conf file on all their hosts? Seems to me this is much harder
than the router configuration.
You do realise that it is easy to do completly automate this as ULA
come from a well defined address block. A simple tool can generate
this for the older machines which haven't been updated to know about
ULAs
Sure, or, you can use PI without ULA and not need to develop a tool.
If you have a interface configured with a ULA address. Take that
address, generate two entries. One for /48 and one for the /64.
Preference the ULA/64 addresses first (link).
Preference the ULA/48 addresses next (site).
Preference the PA/PI/6to4/64 addresses next (link).
Preference the PA/PI/6to4/48 addresses next (site). (a RA would be a good way
to distribute the site size other than /48 for PA/PI).
Preference 2000::/3 next.
Preference 2002::/16 next.
[2000::/3 2002::/16 reverse order if you don't have any non-ULAs outside of
2002::/16]
Preference fc00::/7 last.
For ULA/64 destination select a source address from the corresponding ULA/64.
For ULA/48 destination select a source address from the corresponding ULA/48.
For PA/PI/6to4/64 destination addresses select a source address from the corresponding PA/PI/6to4/64.
For PA/PI/6to4/48 destination addresses select a source address from the corresponding PA/PI/6to4/48.
For 6to4 destination addresses not already handled select a 6to4 address if available then a PA/PI source address and ULA address last.
For 2000::/2 destination addresses not already handled select a PA/PI source address then 6to4 addres and ULA address last.
For ULA destination addresses not already handled select a PA/PI source address then 6to4 addres and ULA address last.
Now is that really so hard?
It just took you 20+ lines to describe the process in english without producing a single
line of code. PI without ULA strikes me as being a lot less complicated.
I'm not sure where the IETF is with revising the default address
selection rules but ULA came out after the first set of rules was
published so it needs to be taken into account if it hasn't already
been.
It doesn't matter where the IETF is. What matters is how many systems
are deployed with what address selection rules and how long they would
take to change if IETF ever did make up their mind on new standards.
If you are merging two sites you just extend the ULA of one to cover
the other as well then slowly deprecate the other or tweak the rules
above and distribute them via DHCP.
Or you use PI and don't worry about it at all.
You're making a very good case fro why ULA is vastly inferior to PI.
Owen
In message <2CE5A700-EB60-453F-85CF-5E679E94EE4C@delong.com>, Owen DeLong write
s:
<massive snip>
>>>=20
>> Actually, gethostbyname returns a linked-list and applications should
>> try everything in the list until successfully connecting. Most do.
>>=20
>> However, the long timeouts in the connection attempt process make
>> that a less than ideal solution. (In fact, this is one of the main =3D
>> reasons
>> that Google does not publish AAAA records generally today).
>>=20
>> However, that isn't the issue above. The issue above is about whether
>> or not:
>> getaddrinfo() always returns the addresses to be tried in proper
>> order.
>> Applications are always well behaved in attempting connections
>> in the order returned by getaddrinfo()
>> Whether the deployment of the gal.conf file to hosts in order to
>> give getaddrlinfo() the correct hints about ordering is
>> likely to occur correctly and reliably.
>> etc.
>>=20
>> There are many dependencies to making source address selection
>> in IPv6 work correctly. They are exacerbated in a ULA environment.
>> If you thought putting a single address (or prefix) into a CPE router
>> by hand was hard, do you really expect the customer to manage
>> a gal.conf file on all their hosts? Seems to me this is much harder
>> than the router configuration.
>=20
> You do realise that it is easy to do completly automate this as ULA
> come from a well defined address block. A simple tool can generate
> this for the older machines which haven't been updated to know about
> ULAs
>=20
Sure, or, you can use PI without ULA and not need to develop a tool.
Actually PI is WORSE if you can't get it routed as it requires NAT or
it requires MANUAL configuration of the address selection rules to be
used with PA.
If you can get PI *and* get it routed then yes PI is the way to go.
PA alone is also not the way to go.
> If you have a interface configured with a ULA address. Take that
> address, generate two entries. One for /48 and one for the /64.
>=20
> Preference the ULA/64 addresses first (link).=20
> Preference the ULA/48 addresses next (site).
> Preference the PA/PI/6to4/64 addresses next (link).
> Preference the PA/PI/6to4/48 addresses next (site). (a RA would be a =
good way
> to distribute the site size other than /48 for PA/PI).
> Preference 2000::/3 next.=20
> Preference 2002::/16 next.
> [2000::/3 2002::/16 reverse order if you don't have any non-ULAs =
outside of
> 2002::/16]
> Preference fc00::/7 last.
>=20
> For ULA/64 destination select a source address from the corresponding =
ULA/64.
> For ULA/48 destination select a source address from the corresponding =
ULA/48.
> For PA/PI/6to4/64 destination addresses select a source address from =
the corresponding PA/PI/6to4/64.
> For PA/PI/6to4/48 destination addresses select a source address from =
the corresponding PA/PI/6to4/48.
> For 6to4 destination addresses not already handled select a 6to4 =
address if available then a PA/PI source address and ULA address last.
> For 2000::/2 destination addresses not already handled select a PA/PI =
source address then 6to4 addres and ULA address last.
> For ULA destination addresses not already handled select a PA/PI =
source address then 6to4 addres and ULA address last.
>=20
> Now is that really so hard?
>=20
It just took you 20+ lines to describe the process in english without =
producing a single
line of code. PI without ULA strikes me as being a lot less complicated.
And PA alone doesn't work well.
As for lines of code they won't be many as basically it is just
inserting/removing rules when addresses are assigned/removed to/from
interfaces.
not everyone's network requires 'routed' ... wrt the internet.
In message <2CE5A700-EB60-453F-85CF-5E679E94EE4C@delong.com>, Owen DeLong write
s:
<massive snip>
=20
Actually, gethostbyname returns a linked-list and applications should
try everything in the list until successfully connecting. Most do.
=20
However, the long timeouts in the connection attempt process make
that a less than ideal solution. (In fact, this is one of the main =3D
reasons
that Google does not publish AAAA records generally today).
=20
However, that isn't the issue above. The issue above is about whether
or not:
getaddrinfo() always returns the addresses to be tried in proper
order.
Applications are always well behaved in attempting connections
in the order returned by getaddrinfo()
Whether the deployment of the gal.conf file to hosts in order to
give getaddrlinfo() the correct hints about ordering is
likely to occur correctly and reliably.
etc.
=20
There are many dependencies to making source address selection
in IPv6 work correctly. They are exacerbated in a ULA environment.
If you thought putting a single address (or prefix) into a CPE router
by hand was hard, do you really expect the customer to manage
a gal.conf file on all their hosts? Seems to me this is much harder
than the router configuration.
=20
You do realise that it is easy to do completly automate this as ULA
come from a well defined address block. A simple tool can generate
this for the older machines which haven't been updated to know about
ULAs
=20
Sure, or, you can use PI without ULA and not need to develop a tool.
Actually PI is WORSE if you can't get it routed as it requires NAT or
it requires MANUAL configuration of the address selection rules to be
used with PA.
It's very easy to get PIv6 routed for free, so, I don't see the issue there.
If you can get PI *and* get it routed then yes PI is the way to go.
PA alone is also not the way to go.
OK, so, PI is the way to go, since you can get it routed for free.
(If you don't know how, see http://tunnelbroker.net and look for the
subject "BGP tunnel")
If you have a interface configured with a ULA address. Take that
address, generate two entries. One for /48 and one for the /64.
=20
Preference the ULA/64 addresses first (link).=20
Preference the ULA/48 addresses next (site).
Preference the PA/PI/6to4/64 addresses next (link).
Preference the PA/PI/6to4/48 addresses next (site). (a RA would be a =
good way
to distribute the site size other than /48 for PA/PI).
Preference 2000::/3 next.=20
Preference 2002::/16 next.
[2000::/3 2002::/16 reverse order if you don't have any non-ULAs =
outside of
2002::/16]
Preference fc00::/7 last.
=20
For ULA/64 destination select a source address from the corresponding =
ULA/64.
For ULA/48 destination select a source address from the corresponding =
ULA/48.
For PA/PI/6to4/64 destination addresses select a source address from =
the corresponding PA/PI/6to4/64.
For PA/PI/6to4/48 destination addresses select a source address from =
the corresponding PA/PI/6to4/48.
For 6to4 destination addresses not already handled select a 6to4 =
address if available then a PA/PI source address and ULA address last.
For 2000::/2 destination addresses not already handled select a PA/PI =
source address then 6to4 addres and ULA address last.
For ULA destination addresses not already handled select a PA/PI =
source address then 6to4 addres and ULA address last.
=20
Now is that really so hard?
=20
It just took you 20+ lines to describe the process in english without =
producing a single
line of code. PI without ULA strikes me as being a lot less complicated.
And PA alone doesn't work well.
Where did PA enter into my statement above?
As for lines of code they won't be many as basically it is just
inserting/removing rules when addresses are assigned/removed to/from
interfaces.
And then distributing those rules to EVERY host (or you have to pre-
distribute the script to EVERY host).
<snip>
Owen
It may be very easy to get it routed for free *now*.
Will it be possible to get PIv6 routed for free once there's 300K entries in
the IPv6 routing table? Or zillions, as everybody and their pet llama start
using PI prefixes? (Hey, if you managed to get PI to use instead of using an
ULA, and routing it is "free", may as well go for it, right?)
Hello-
Would someone with clue within the Verizon team contact me off-list, please?
I'm not seeing rDNS entries for "new" fios ip addresses.
Regards,
Ed Trdina
Hopefully by the time it gets to that point we'll have finally come up with a
scaleable routing paradigm. Certainly we need to do that anyway. I'm not
sure why we chose not to do that with IPv6 in the first place.
Owen
because:
1) there were only going to be a limited number of ISP's
b) every end site gets PA only
iii) no need for pi
d) all of the above
I understand how they rationalized the cop-out. Now, getting back to the
real world...
Owen
If you're going to start a new thread on a mailing list your best bet is to copy the list address to your address book, and create a new message. By replying to another message and changing the topic your message shows up "buried" under the thread you replied to. This is particularly bad when you're trying to get someone's attention (as you are here). 
hth,
Doug
You should probably start a new thread rather than burying your request
inside a really long one that someone who could help could be ignoring.
(Hint: changing the subject doesn't do that.)
~Seth
My guess is that the millions of residential users will be less and
less enthused with (pure) PA each time they change service providers...
Hi, almost everytime I open my laptop it gets a different ip address,
sometimes I'm home and it gets that same ip it had the last time I was
there.
once in a very great while my home gateway changes it's ip address,
since it does dynamic dns updates I have no trouble finding it, and in
fact the network storage perhipheral that I have thinks nothing of using
upnp to punch a hole in the gateway all on it's own... These are mostly
low touch and either zero or very little configuration required.
The consumer isn't got to tollerate systems which don't work
automatically or very nearly so, which means among other things having
an ip address change or even have your home gateway(s) help the
downstream devices renumber themselves.
That claim seems to be unsupported by current experience. Please elaborate.
It's not only not supported by current experience it seems really
unlikely to be supported by future experience, e.g. many device you have
are mobile, and a connected to more than one network at a time they
still may be gatewaying for downstream devices. if somewhere along the
line you solved this for the mobility case it is going to work for
networks which are more stable.