Subject: [v6ops] Why not use the L-flag?: Unique IPv6 Prefix per Host

From: Stephen Honlue <[email-masked]>
Date: Thu, 9 Nov 2017 18:56:33 +0000

Hi all,

I went through the draft:
https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-13

I noticed that the only valid intend of the draft is EU isolation, and I
know this is achievable using the L-flag set to 0 as described inRFC
4861 <https://tools.ietf.org/html/rfc4861>Page 29.

Assuming the WG is ok with this draft, what happens to the rest of say
[(2^64) - 1] IPs at the host level, considering that the EU needs only
one IP.

Am I missing something?

---

Musa

---

From: Mark Smith <[email-masked]>
Date: Fri, 10 Nov 2017 06:13:47 +1100

On 10 November 2017 at 05:56, Stephen Honlue <[email-masked]> wrote:
> know this is achievable using the L-flag set to 0 as described in RFC 4861
> Page 29.
>

The host is given the whole prefix, so all of the addresses are
present on the host itself.

The L-bit is for the situation when a prefix is shared between a
number of host on a link, and the host is being instructed on how to
reach other addresses in the prefix - directly across a the link, or
via a default router.

> [(2^64) - 1] IPs at the host level, considering that the EU needs only one
> IP.
>

This is the fundamental thing about this. A host is being given many
addresses (effectively as many as it wants), by giving it a whole
prefix to use as it likes. This is "bulk" host address assignment
rather than individual host address assignment.

We think it is a good idea that hosts aren't constrained in terms of
addresses as there is no need for them to be in IPv6. Fundamentally,
if an IPv6 host can't get an address, then the fundamental goal of
IPv6 - providing more addresses - hasn't been achieved.

Here's the BCP making that recommendation:

Host Address Availability Recommendations
https://tools.ietf.org/html/rfc7934

Regards,
Mark.

> Am I missing something?
>
> ---
>
> Musa
>
>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Stephen Honlue <[email-masked]>
Date: Thu, 9 Nov 2017 19:34:44 +0000

> reach other addresses in the prefix - directly across a the link, or
The provider managed shared network is nothing but a link. And if a
prefix is sent on that link with the L-bit set to 0, we already get the
devise isolation intended to be provided by this draft.
> https://tools.ietf.org/html/rfc7934
Thanks for sharing.

---

From: Mark Smith <[email-masked]>
Date: Fri, 10 Nov 2017 06:49:15 +1100

> devise isolation intended to be provided by this draft.

The prefix is not sent "on the link" (sent to all hosts on the link),
it is sent specifically to an individual host via a unicast RA. Each
host has its own unique prefix.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Nov 2017 09:33:49 +1300

On 10/11/2017 08:49, Mark Smith wrote:
>> The provider managed shared network is nothing but a link. 

As was discussed earlier, whether it's physically a point-to-point
link from the switch port**, or actually a shared medium like Wi-Fi
or traditional Ethernet, is an open question. By using the unicast
link-layer address, this operational mechanism will work in either case.

** Of course, there could be a point-to-point link from the switch,
which is also the router, but with a dumb Ethernet switch at the
far end, converting the point-to-point link back into a shared
medium. This operational mechanism will work in that case too.
Given the nature of Ethernet, that is a necessary property.
The L bit is not enough.

>> And if a

Exactly, regardless of how the packets actually reach it.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Mon, 13 Nov 2017 19:30:32 +1100

On 29 Oct. 2017 09:20, "Ted Lemon" <[email-masked]> wrote:

On Oct 28, 2017, at 5:59 PM, Tom Herbert <[email-masked]> wrote:

Some of this has been touched upon in the IDEAS discussions, but nothing
formalized yet (identifier-locator use implied to eliminate as much
topology on address as possible). I could spin a draft specifically on one
time use addresses and privacy (won't make cutoff though).

The problem is that now you have a requirement for substantial
infrastructure to manage the ID/locator separation.   Would look a bit like
Tor.   Who's going to pay for it?

Actually, I think multipathing e.g. MPTCP goes a long way to solving that
problem. The 32 bit token generated and used by subflows to identify their
peer is a temporary host ID that is independent of the locators/addresses
of the host.

My understanding is that in "original" ID/locator separation, the host ID
was expected to be fixed and bound to a host across many transport layer
connections. Perhaps that's what makes it a hard problem.

Temporary, per application session host IDs are also better for privacy.

Regards,
Mark.

---

From: Tom Herbert <[email-masked]>
Date: Mon, 13 Nov 2017 11:42:25 -0800

On Mon, Nov 13, 2017 at 12:30 AM, Mark Smith <[email-masked]> wrote:
> formalized yet (identifier-locator use implied to eliminate as much topology
> on address as possible). I could spin a draft specifically on one time use
> addresses and privacy (won't make cutoff though).
>
>
> peer is a temporary host ID that is independent of the locators/addresses of
> the host.
>
Mark,

The idea of single use addresses is that a host can be assigned many
identifiers from which it can create a unique source address for each
connection. It is up to the infrastructure to direct packets for each
addresses to the right end host. It's true this is potentially a lot
of state for the infrastructure to manage, but the total number of
state entries would be no more than the number of NAT entries if that
were in use today so I don't believe it is impractical.

> Temporary, per application session host IDs are also better for privacy.
MPTCP can also leverage this as a means to effectively change the
source address of an existing connection in order to benefit privacy
for long lived connections.

Tom

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Nov 2017 10:29:51 +0800

> were in use today so I don't believe it is impractical.

The problem is that the goal for doing this would be to obscure, as much as possible, the identify associated with a particular flow.   In order to do this, it has to be the case that the locater used to route that flow reveals as little as possible to the remote endpoint of the flow: that is, that if I connect to you, in principle the return address you see is as unspecific as possible.

In order for that to work, the mapping has to be as high in the network hierarchy as possible.   If the point in the network hierarchy where the mapping occurs is, say, in my home gateway, then not much obscuration of identity is being accomplished.   Perhaps the remote endpoint does not know who in my home connected, but it knows someone in my home did.

If you do the mapping one level up, at the ISP's local data center, then now all the remote endpoint knows is that someone in, say, Brattleboro (the town where I live), who is a Comcast customer, connected.   If you do the mapping another level up, then all the remote endpoint knows is that someone in, say, New England, who is a Comcast customer, connected.   And so on.

Of course, the higher up in the hierarchy that you do the mapping, the easier it is to monitor below the mapping point, since our adversary may not be on the remote endpoint.   In the case of government surveillance or ISP monetization of search traffic, if the mapping occurs at the top of the ISP, and the monitoring occurs within the ISP's network, then a fairly specific identity is available to the adversary.

This is why Tor does multiple layers of mapping, on multiple routers.   In order to get a similar degree of obfuscation, a similar mapping process would be required.   This requires substantial infrastructure, and is in no way analogous to the cost of network address translation, even CGN.   These translators ideally need to be under the control of a variety of entities, such that no one entity can reveal the identity of the protected endpoint.

This is why I made the original comment, "who pays for this?"   There's no reason in principle why something like this couldn't be set up, but to be available to every end user, a rather massive cost would have to be absorbed by someone.   Who would that be?

---

From: Tom Herbert <[email-masked]>
Date: Mon, 13 Nov 2017 19:38:26 -0800

On Mon, Nov 13, 2017 at 6:29 PM, Ted Lemon <[email-masked]> wrote:
> The problem is that the goal for doing this would be to obscure, as much as
> possible, the identify associated with a particular flow.   In order to do
> this, it has to be the case that the locater used to route that flow reveals
> as little as possible to the remote endpoint of the flow: that is, that if I
> connect to you, in principle the return address you see is as unspecific as
> possible.
>

Hi Ted,

I don't believe that locators should be visible outside of the network
infrastructure since they do tend to reveal specific location
especially as would the case of mobile networks. The outside world
should only see an eternally visible that contains the prefix of the
provider and an identifier without any more specific topology
information. A third party should only be able to deduce the provider
and nothing more more from just the address.

> In order for that to work, the mapping has to be as high in the network
> hierarchy as possible.   If the point in the network hierarchy where the
> mapping occurs is, say, in my home gateway, then not much obscuration of
> identity is being accomplished.   Perhaps the remote endpoint does not know
> who in my home connected, but it knows someone in my home did.
>
The identifier space would be at least 64 bits, so the home gateway
can get multiple addresses from the provider and hand them to local
devices. Given two connections, from the home network they would have
completely different source addresses except for the common network
provider prefix.

> If you do the mapping one level up, at the ISP's local data center, then now
> all the remote endpoint knows is that someone in, say, Brattleboro (the town
> where I live), who is a Comcast customer, connected.   If you do the mapping
> another level up, then all the remote endpoint knows is that someone in,
> say, New England, who is a Comcast customer, connected.   And so on.
>
As I said above customers don't see locators. It's analogous to
networks tunneling customers packets over their infrastructure without
knowledge.

> Of course, the higher up in the hierarchy that you do the mapping, the
> easier it is to monitor below the mapping point, since our adversary may not
> be on the remote endpoint.   In the case of government surveillance or ISP
> monetization of search traffic, if the mapping occurs at the top of the ISP,
> and the monitoring occurs within the ISP's network, then a fairly specific
> identity is available to the adversary.
>
> This is why Tor does multiple layers of mapping, on multiple routers.   In
> order to get a similar degree of obfuscation, a similar mapping process
> would be required.   This requires substantial infrastructure, and is in no
> way analogous to the cost of network address translation, even CGN.   These
> translators ideally need to be under the control of a variety of entities,
> such that no one entity can reveal the identity of the protected endpoint.
>
> This is why I made the original comment, "who pays for this?"   There's no
> reason in principle why something like this couldn't be set up, but to be
> available to every end user, a rather massive cost would have to be absorbed
> by someone.   Who would that be?

There's already significant deployment of identifier/locator split in
network virtualization. Mobile networks are an emerging use case,
identifier-locator split provides a mechanism for mobility (moving
devices ant its addresses from on point of attachment to another). The
notion of single use addresses is enabled by identifier-locator split
as one possible use case.

Tom

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Nov 2017 13:53:47 +0800

> as one possible use case.

It makes sense to do this in mobile because you want the handset to be able to move without breaking connections, so that's an example of "who pays."   But in this case are these mobile providers currently doing one-locator-per-connection, or are they currently doing one-locator-per-host?

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 15 Nov 2017 00:47:34 +0800

On Tue, Nov 14, 2017 at 1:53 PM, Ted Lemon <[email-masked]> wrote:

> It makes sense to do this in mobile because you want the handset to be
> able to move without breaking connections, so that's an example of "who
> pays."   But in this case are these mobile providers *currently* doing
> one-locator-per-connection, or are they *currently *doing
> one-locator-per-host?
>

Currently all mobile providers provide a /64 per host and that can't be
done with identifier/locator split.

---

From: Tom Herbert <[email-masked]>
Date: Tue, 14 Nov 2017 08:59:29 -0800

On Tue, Nov 14, 2017 at 8:47 AM, Lorenzo Colitti <[email-masked]> wrote:
>> pays."   But in this case are these mobile providers currently doing
>> one-locator-per-connection, or are they currently doing
>> one-locator-per-host?
>
>
> Currently all mobile providers provide a /64 per host and that can't be done
> with identifier/locator split.

Lorenzo,

Identifier/locator split can route /64 per host. This is already done
via encapsulation, but I do think we have a solution for ILA without
needing encapsulation. However, if privacy is the top goal then you
really want single use addresses, /128s per connection. This achieves
a similar effect for privacy that NAT gives without having the
ugliness of NAT.

Tom