Subject: Re: [BEHAVE] NAT66 and dynamic Ipv6 allocations

From: Dave Thaler <[email-masked]>
Date: Tue, 2 Dec 2008 18:14:04 -0800

Any entity doing referrals should not just "pick one" address.
It should "pick all" (globally unique ones anyway) or else just use a name
(for cases where there exists a resolvable name).

In IPv6 we have the luxury of having globally unique addresses.
The notion that a referral can only use one is something I think we should avoid,
and fix things that can only deal with one address.

-Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Keith Moore
Sent: Wednesday, November 26, 2008 10:51 PM
To: Brian E Carpenter
Cc: Roque Gagliano; [email-masked]
Subject: Re: [BEHAVE] NAT66 and dynamic Ipv6 allocations

Brian E Carpenter wrote:
> Roque,
>
>> So, what his made me think is about the necessity of a NAT66 when having
>> (for any reasons) dynamic IPv6 allocations by ISPs. It could make sense
>> to maintain long living IPv6 addresses in the inside side, while the ISP
>> is playing with your public side.
>
> What's wrong with the standard IPv6 solution to this, i.e., use a ULA
> prefix for internal traffic, and only use a global prefix, in your
> case 6to4, for external traffic?

I've never figured out how applications are supposed to know, absent
explicit configuration for every application, whether traffic is
"internal" or "external".  In particular for any multiparty application
that does referrals, it doesn't suffice to simply choose the source
address based on the destination address.  What matters is whether all
of the application's peers are "internal" or "external" and the
application may not know that a priori.

Keith
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Dec 2008 00:58:56 -0500

> (for cases where there exists a resolvable name).

Yes, an application can be designed so that referrals send all globally
unique addresses to a peer.  There are a few caveats though:

- Even if an application has several global addresses to choose from,
trial and error is still a poor means of deciding which one to send to.
 this is true regardless of whether the addresses came from DNS lookup
or from a referral (after all, a DNS response is a kind of referral)

- Trial and error can involve both the source and destination address.
if each host has N usable addresses on average, you get N**2 potential
trials on average.  That's fine as long as each of them has a high
probability of working well, not so good if it really  matters which
addresses are picked.

- If some addresses are only usable within certain realms, that makes
life more difficult.  Note that it's hard to avoid that model,
particular for ad hoc and intermittently connected, nomadic networks.

- If a connection is established with one pair of endpoint addresses and
it later fails (due to link failure or insufficient capacity or an
endpoint renumbering or whatever), many applications can't gracefully
fail over to another pair of endpoint addresses.   And this isn't
something that we should expect applications in general to be able to do
- it ought to be handled by the transport layer or below.

The model where an application can obtain a single address that should
always work is much simpler, if you can get there.  Failing that, the
fewer addresses that an application has to choose from in order to reach
a peer, and the less likely that such a choice will fail within the
duration of the association, the better.

> and fix things that can only deal with one address.

I concur - apps need to be able to deal with multiple addresses.

  But something else we should avoid is the notion that it's fine for
apps to have to deal with selecting between multiple source and/or
destination addresses, where the choice matters much.  Especially to
recover from a link failure or renmubering that caused a broken
connection with a particular instance of an application.

Keith