Subject: [v6ops] draft-ietf-v6ops-64share

From: Michael Richardson <[email-masked]>
Date: Tue, 30 Jul 2013 07:44:04 -0400

Cameron, which scenario does the Android AOSP use?
Are the concerns about applications caring about the prefix length real?

I sure prefer scenario 1.  I think that MIF-aware applications will be
happier with two v6 addresses.

(I think that privacy extensions are useless for a device/network which likely
has the same /64 all the time)

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: "cb.list6" <[email-masked]>
Date: Tue, 30 Jul 2013 07:08:41 -0700

> Cameron, which scenario does the Android AOSP use?

Aosp has not integrated this yet, but this implementation was submitted

http://dan.drown.org/android/clat/

Scenario 2 is  used. There is value in the device being able maintain
communication (sockets) while tethering is turned on and off. Voip is a
good example of something that should not bounce when tethering is turned on

> Are the concerns about applications caring about the prefix length real?

I was given feedback that some apps care, and it should be noted

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 30 Jul 2013 16:10:21 +0200

> Are the concerns about applications caring about the prefix length real?

I doubt that the prefix length is a real concern. Do we have any examples
of this?

> happier with two v6 addresses.

Why? One would hope that a MIF-aware application would understand that it's
possible to have an IP address on one interface and use it on another
interface.

(I think that privacy extensions are useless for a device/network which
> likely

It doesn't have the same /64 all the time. When you lose coverage or switch
to wifi, when you come back to the 3G network you'll get a different prefix.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 Jul 2013 10:53:47 -0400

> communication (sockets) while tethering is turned on and off. Voip is a good
    > example of something that should not bounce when tethering is turned on

I don't understand.
Why does adding a second IP address change anything that is already alive?

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 Jul 2013 10:56:43 -0400

Lorenzo Colitti <[email-masked]> wrote:
    mcr> I sure prefer scenario 1.  I think that MIF-aware applications will be
    mcr> happier with two v6 addresses.

    > possible to have an IP address on one interface and use it on another

Ideally, a MIF aware application would see the same IP address on two different
interfaces as being in two entirely different domains.
Having one IP makes debugging and human stuff harder.

    mcr> (I think that privacy extensions are useless for a device/network which
    mcr> likely
    mcr> has the same /64 all the time)

    > It doesn't have the same /64 all the time. When you lose coverage or switch to
    > wifi, when you come back to the 3G network you'll get a different prefix.

That's might be true, but I really hope that they give me the same /64 when
I'm in the same place, so that I can have longer lived incoming connections.
Otherwise, I might as well NAT66 :-)

---

From: "cb.list6" <[email-masked]>
Date: Tue, 30 Jul 2013 08:03:40 -0700

> Why does adding a second IP address change anything that is already alive?

It should not, i agree.  So, i am a little confused by your question.

Scenario 1 moves the prefix from WAN to LAN, this may break an open connection.

Scenario 2 replicates the IP on 2 interfaces

Are you suggesting that we simply keep the /128 on the WAN and put the
/64 on the LAN with normal SLAAC and new LAN inteface IP?  The issue
with that, is that on the LAN, the /128 on the WAN is not accounted
for and may cause a conflict / duplicate, so it is easier to make the
WAN and LAN intefaces IP the same

CB

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 30 Jul 2013 17:42:23 +0200

> interfaces as being in two entirely different domains.

Off-topic, but I don't think this is a fair assumption. The source of the
information should determine what domain it's in, not the interface.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 30 Jul 2013 17:50:38 +0200

> Scenario 2 replicates the IP on 2 interfaces

Why do we document these two as completely separate "scenarios"? As far as
I can see these "scenarios" are simply two ways of meeting the same
requirement, which is "the phone must not allow a tethered client to use an
IP address that is being used by the phone". Instead of having most of the
content of the document duplicated into two mostly-identical scenarios, can
we just list that requirement and provide two example ways of doing it?

(Neither of the two is correct, BTW - the right thing to do is for the
phone to keep all the addresses assigned to the northbound interface and
defend all of them against DAD on the southbound interfaces.)

---

From: Ted Lemon <[email-masked]>
Date: Tue, 30 Jul 2013 15:55:20 +0000

On Jul 30, 2013, at 5:42 PM, Lorenzo Colitti <[email-masked]> wrote:
> Off-topic, but I don't think this is a fair assumption. The source of the information should determine what domain it's in, not the interface.

There is terminology in the MIF architecture document that I think would help to clarify this discussion if the participants are interested.   Lorenzo is right, and Michael is also right, depending on whether the duplicate IP address is in one explicit provisioning domain or in two explicit or implicit provisioning domains.   It can't ever be in a single implicit provisioning domain.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 Jul 2013 12:19:02 -0400

cb.list6 <[email-masked]> wrote:
    mcr> I don't understand.
    mcr> Why does adding a second IP address change anything that is already alive?

    > Scenario 1 moves the prefix from WAN to LAN, this may break an open connection.

Ah, I understand, the operation of moving the prefix, if done as break before
make, which is required sometimes, might kill connections.

    > WAN and LAN intefaces IP the same

I wonder if this is really true.
I know that Linux, by default, with a weak host model, will answer IPv4 ARP
for interface 2, when asked for it on interface 1. (Many think this is a bug,
even a security bug, and there are options in 2.6.8-ish to disable that)

I will try the same thing with DAD. I have a test bench where this will be easy.
I imagine it ought to fail, but I could be wrong.  It is something that could
be fixed if desired.  I don't know what the specification say, and if
weak/strong host model was even taken into account here.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 Jul 2013 12:19:55 -0400

Lorenzo Colitti <[email-masked]> wrote:
    mcr> Ideally, a MIF aware application would see the same IP address on two
    mcr> different
    mcr> interfaces as being in two entirely different domains.

    > information should determine what domain it's in, not the interface.

point taken.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 30 Jul 2013 18:29:39 +0200

> weak/strong host model was even taken into account here.

I believe you'll find that it doesn't work. If nothing else, it doesn't do
MLD joins on all interfaces when you add an address to one interface.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Jul 2013 10:13:40 +1200

> There is terminology in the MIF architecture document that I think would help to clarify this discussion if the participants are interested.   Lorenzo is right, and Michael is also right, depending…

IMHO the question is broader than the phrase "provisioning domain" implies.
That is about where the address comes from. The more general aspect is
the scope of reachability of the address.

I came to the conclusion a few years ago that we need a generic way of
naming an individual scope of reachability (which in the case under
discussion might mean the union of two provisioining domains, but
who knows?). If the metadata for a prefix included all the scopes
of reachability that apply to it, things might be easier.

(There is some specfic text about this notion in section 2 of
http://tools.ietf.org/html/draft-carpenter-grobj-reqts-00).

    Brian

---

From: Ted Lemon <[email-masked]>
Date: Wed, 31 Jul 2013 07:57:53 +0000

> of reachability that apply to it, things might be easier.

An implicit provisioning domain is one that wasn't specified, but assumed by the host.   A formal provisioning domain is specified by configuration information received from the network. The architecture doc requires that in order for two provisioning domains to be the same, they have to both be formal and be securely validated.

It seems to me that reachability is a property of an advertised prefix, and not of a provisioning domain.   So if you have the same IP address on two interfaces, you have the same prefix, and hence the same reachability, with respect to that prefix.

Obviously if the reachability isn't the same this will cause problems, but I think that's a configuration error.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 01 Aug 2013 16:56:48 +1200

> It seems to me that reachability is a property of an advertised prefix, and not of a provisioning domain.   So if you have the same IP address on two interfaces, you have the same prefix, and hence…

Yes, but the problem is that we don't know how to express this, for a scope
that isn't entirely local or entirely global.

> Obviously if the reachability isn't the same this will cause problems, but I think that's a configuration error.

Or a failure to communicate the actual configuration to the recipient
of the prefix advertisement.

I guess I'm saying that if we solve this problem only for the case
of provisioning domains (as defined by MIF), we haven't solved the
general case (where there may be arbitrary filters or missing
routes upstream from the various interfaces). It may not even be
soluble, in which case we'll need happy-eyeballs-like solutions
for ever.

   Brian