Subject: Identifier/locator split addressing and /64

From: Tom Herbert <[email-masked]>
Date: Tue, 6 Jun 2017 08:54:54 -0700

Both RFC7421 and RFC7136 state that a motivation for the /64 is
identfier/locator split addressing (like in ILNP). The motivation is
valid, however assigning a /64 to UEs in a mobile network is not
compatible with identifier/locator split. The reason is that the link
of interest for IIDs is not inside the UE, but is logically in the
network. The identifier in a mobile network needs to identify the
device.

In identifier/locator split, the IP address is split into a locator
and identifier. Each are 64 bits (although Brian did point out that
that could also be a parameter). Just like IIDs, identifiers must be
unique within the subnet. In the case of a mobile network the link is
an overlay network that is not physical, but none the less it is a
type of link.
So the properties of it being a link including those for IIDs on the
link hold-- this make identifiers equivalent to IIDs by definition.

The IPv6 address for identifier/locator split looks like:

M bits for locator
N bits for device identifier
128 - M - N bits for addresses within the device

M is 64, and it seems straightforward to make N be 32 so we get

64 bits for locator
32 bits for device identifier
32 bits for addresses within the device

Which implies /96 assignment to each UE.

Thus the IID is constructed from a 32 bit number assigned to the
device, and a 32 bit number assigned by the device. If assignments for
both of these are randomized this provides 64 bits of entropy for
security.

Tom

---

From: [email-masked]
Date: Tue, 6 Jun 2017 18:02:20 +0200

Tom,

> both of these are randomized this provides 64 bits of entropy for

Can you explain how this is different from a device getting multiple 64-bit IIDs?

Cheers,
Ole

---

From: Tom Herbert <[email-masked]>
Date: Tue, 6 Jun 2017 09:20:32 -0700

> Can you explain how this is different from a device getting multiple 64-bit IIDs?
Hi Ole,

I'm not sure I understand the question, but each device is getting
2^32 64-bit IIDs in this scheme. Uniqueness of IIDs within the subnet
is ensured by the device identifier. This conforms with RFC3513:

"Interface identifiers in IPv6 unicast addresses are used to identify
interfaces on a link.  They are required to be unique within a subnet
prefix."

Tom

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 6 Jun 2017 12:34:43 -0400

Tom, I do not follow your reasoning at all.
I can not tell what you mean by "addressing within the device".
Even in a data center, one might choose to treat the hypervisor as part 
of the network, and allocate a prefix to the hypervisor so it can assign 
a /64 locator to each device.  Or you could assign separate /64s to each 
entitiy within the device from the network directly.  Neither requires 
changing the IID space.

For something that is a single device, like a UE< it is even simpler to 
allow the network to directly assign as many /64 as the device needs.

Note that if the UE is serving as a router for other devices, then
1) that is not routing within the device
2) the space is likely small enough that routing on the full /128s works 
just fine

You have made this assertion a couple of times now, and I can not figure 
out why you consider the change necessary.  ILNP can work fine for 
mobile network UE.

Yours,
Joel

On 6/6/17 11:54 AM, Tom Herbert wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 6 Jun 2017 10:33:23 -0700

Hi Joel,

> I can not tell what you mean by "addressing within the device".

Referring to the prefix delegated to the device.

> Even in a data center, one might choose to treat the hypervisor as part of
> the network, and allocate a prefix to the hypervisor so it can assign a /64
> locator to each device.  Or you could assign separate /64s to each entitiy
> within the device from the network directly.  Neither requires changing the
> IID space.
>
Right, we're not changing the IID space here. We're specifying which
link (subnet) is the IID space relative to.

> You have made this assertion a couple of times now, and I can not figure out
> why you consider the change necessary.  ILNP can work fine for mobile
> network UE.

It doesn't work if the UE is assigned a /64, that's my point. The
device is the mobile node that needs to be reflected in the identifier
and then the mapping in the network is mobile device (device
identifier) to locator. The locator is the address of an attachment
point (e.g. base station) in the network. The addresses covered by the
prefix assigned to the device is not relevant in mobility since the
whole prefix follows the device. So what we're really interested in is
which mobile device is the packet being sent to and where is it in the
mobile network.

I'll give it a shot to show by example.

Suppose we have a mobile network. Base stations have addresses in the
form 2000:0:0:X:: where X is unique for each base station. UEs are
assigned /64 in the form 3000:0:0:Z::/64 where Z addresses the UE.

Consider a packet is sent to an address within a mobile node with
external address 3000:0:0:123:0:0:0:1. Assume the device is attached
to base station with address 2000:0:0:567::. In identifier/locator the
top sixty-four bits of address are overwritten with the locator for
forwarding so the destination becomes 2000:0:0:567:0:0:0:1. The packet
will reach the correct base station, but we've lost the address
information for the device so the base station has no way to forward
it on.

Alternatively, assume the identifier is composed of a 32 bit device
identifier and 32 bits delegated to UE. Now UEs are assigned /32 in
the form 3000:0:0:0:0:Z::/32.

Consider a packet is sent to 3000:0:0:0:0:123:0:1. Again the top sixty
four bits are overwritten with a locator so the destination on the
wire is 2000:0:0:567:0:123:0:1. The packet reaches the base station,
and it can now be forwarded to the correct device that is identified
by the 0:123 device identifier in the address.

Hope that helps!

Tom

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 6 Jun 2017 14:55:06 -0400

I have several problems with your description.
1) The address of the Base Station for purposes of communciating with 
the base station is irrelevant.
2) More importantly, in ILNP, the upper 64 bits are not "over-written". 
Rather, the sender fills in the correct 64 bits that will route the 
traffic to the right place to reach the UE. Thus, the modile operator 
can allocate the structure of the locators (within their allocated IPv6 
address block) so as to enable the use of effective and scalable IP 
routing to reach the UE without over-writing anything.

I presume it is accidental, but your description of ILNP does not match 
the RFCs, including the ones that discuss mobility and data center handling.

Yours,
Joel

---

From: Tom Herbert <[email-masked]>
Date: Tue, 6 Jun 2017 13:05:23 -0700

On Tue, Jun 6, 2017 at 11:55 AM, Joel M. Halpern <[email-masked]> wrote:
> 1) The address of the Base Station for purposes of communciating with the
> base station is irrelevant.
> Rather, the sender fills in the correct 64 bits that will route the traffic
> to the right place to reach the UE. Thus, the modile operator can allocate
> the structure of the locators (within their allocated IPv6 address block) so
> as to enable the use of effective and scalable IP routing to reach the UE
> without over-writing anything.

Can you provide concrete end to end example for this similar to mine.
That is how an external host can reach an address in a UE that is
moving around in a mobile network.

> I presume it is accidental, but your description of ILNP does not match the
> RFCs, including the ones that discuss mobility and data center handling.
>
I didn't say this was specifically ILNP. The description is consistent with ILA.

Thanks,
Tom

>>> of
>>> out

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 6 Jun 2017 16:44:23 -0400

If what you are now saying Tom is that ILA would work better with a 
different address arrangement, I guess you would know better than I. 
 From what I had seen, it seemed likely that if ILA will work for 
mobiles at all, it will work with the current /64 boundary.  But your 
invention, your judgment.

As for ILNP, if you want to understand how it works, in general, for 
data centers, or for mobility, I suggest reading the RFCs.  Any 
paraphrase I provided in a short email would probably be a disservice 
both to ILNP and to the members of this list.

Yours,
Joel

---

From: Tom Herbert <[email-masked]>
Date: Tue, 6 Jun 2017 19:32:50 -0700

On Tue, Jun 6, 2017 at 1:44 PM, Joel M. Halpern <[email-masked]> wrote:
> different address arrangement, I guess you would know better than I. From
> what I had seen, it seemed likely that if ILA will work for mobiles at all,
> it will work with the current /64 boundary.  But your invention, your
> judgment.
>
> As for ILNP, if you want to understand how it works, in general, for data
> centers, or for mobility, I suggest reading the RFCs.  Any paraphrase I
> provided in a short email would probably be a disservice both to ILNP and to
> the members of this list.
>
Joel,

I did read the drafts and that is what I base my conclusions on.
Section 6 of RFC6740 on mobility indicates that a mobile host has a
unique identifier, so if each host is already being assigned a /64
there is no room left for the host identifier. Section 6.3 about
network mobility indicates that each host in the network is
individually mobile which is even more of a problem.

This is pertinent to the discussion on /64 addressing since in several
RFCs a motivation for that is ILNP or ILA. I claim that assigning /64
to UEs prevents using ILNP, ILA, or any identifier/locator (64/64)
split for mobility.

Tom

>>> traffic
>>> the

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 6 Jun 2017 22:40:36 -0400

In ILNP, the Unique Identifier for the host is used as the lower 64 bits 
of the IPv6 address, while the locator is the upper 64 bits.
This was specifically designed with the 64 bit boundary in mind, and 
works for fixed and mobile hosts.

You say that the boundary causes problems for ILA.  I believe you. 
Having worked through multiple cases, it does not cause any problems for 
the ILNP.

Yours,
Joel

---

From: Erik Kline <[email-masked]>
Date: Wed, 7 Jun 2017 11:57:28 +0900

> to UEs prevents using ILNP, ILA, or any identifier/locator (64/64)

Not really.  The identifier assigned by the 3GPP network is basically what
the modem uses.  In practice, it's just 1 address that's reserved.  In
practice you want to have a function that does a double check of any new
identifier to make sure it's not in use.  If an implementation randomly
generates the same identifier already assigned this will just be a
collision.

I don't think there's any issue here.

Tom
> >>> the structure of the locators (within their allocated IPv6 address
> block)
> >>> so
> >>>>> the network, and allocate a prefix to the hypervisor so it can
> assign a
> >>>>> /64
> >>>>> within the device from the network directly.  Neither requires
> changing
> >>>>> the
> >>>>> IID space.
> >>>>>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 6 Jun 2017 20:05:11 -0700

On Tue, Jun 6, 2017 at 7:40 PM, Joel M. Halpern <[email-masked]> wrote:
> In ILNP, the Unique Identifier for the host is used as the lower 64 bits of
> the IPv6 address, while the locator is the upper 64 bits.
> This was specifically designed with the 64 bit boundary in mind, and works
> for fixed and mobile hosts.
>
> You say that the boundary causes problems for ILA.  I believe you. Having
> worked through multiple cases, it does not cause any problems for the ILNP.
>
Great. Then I ask again "Can you provide concrete end to end example
for this similar to mine?". This would be most helpful.

Thanks,
Tom

>>>>>>> the network, and allocate a prefix to the hypervisor so it can assign
>>>>>>> a
>>>>>>> /64

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 6 Jun 2017 23:18:09 -0400

I am really not sure what example you want, but I will try.

Suppose that each eNodeB is expected to support up to 1000 simultaneous 
UEs.  (I have not checked whether that is the right number, but we can 
use it for working an example.

Then the operator takes his block (say XXX::/32)  And he assigns 11 or 
12 bits of space to each eNodeB.   He assigns the block to the eNODEB 
acording to his addressing plan so that one can easily route to it.  So 
one eNodeB might be allocated XXXYZQ/52, and another might get 
XXXLMN/52, etc.  Where the portion after the XXX is allocated according 
to the topological placement of the eNodeB in the operators network.
The eNodeB then assigns /64 locators from its block to each UE.

(IN practice, due to th4e way mobile network work, the assignments are 
done in a more complicate fashion, but they still simply come out of the 
block associated with each eNodeB.

Node that these blocks have nothing formally to do with the address 
assigned to the eNodeB, although due to simplicity of forwarding one 
might assign eNodeB local addresses from the same blocks.  Or one might 
segregate for reasons of address isolation.  ILNP does not care.

The point is that the UE uses the combination of assigned locator and 
created identifier for its IPV6 communication.  And when the UE moves, 
it sends the ICMP updates to its correspondents.

Beyond that we are getting into operational practices for mobile 
operators, which are not the topic of this discussion.

Yours,
Joel

---

From: Tom Herbert <[email-masked]>
Date: Tue, 6 Jun 2017 20:39:42 -0700

On Tue, Jun 6, 2017 at 8:18 PM, Joel M. Halpern <[email-masked]> wrote:
> Suppose that each eNodeB is expected to support up to 1000 simultaneous UEs.
> (I have not checked whether that is the right number, but we can use it for
> working an example.
>
> Then the operator takes his block (say XXX::/32)  And he assigns 11 or 12
> bits of space to each eNodeB.   He assigns the block to the eNODEB acording
> to his addressing plan so that one can easily route to it.  So one eNodeB
> might be allocated XXXYZQ/52, and another might get XXXLMN/52, etc.  Where
> the portion after the XXX is allocated according to the topological
> placement of the eNodeB in the operators network.
> (IN practice, due to th4e way mobile network work, the assignments are done
> in a more complicate fashion, but they still simply come out of the block
> associated with each eNodeB.
>
> Node that these blocks have nothing formally to do with the address assigned
> to the eNodeB, although due to simplicity of forwarding one might assign
> eNodeB local addresses from the same blocks.  Or one might segregate for
> reasons of address isolation.  ILNP does not care.
>
> created identifier for its IPV6 communication.  And when the UE moves, it
> sends the ICMP updates to its correspondents.
>
I see. What happens if a peer doesn't get the ICMP message, the 12 bit
identifier (same 64 bit locator) is assigned to a new UE in the
eNodeB, and then the peer wakes up and sends using the now using the
out of date locator that reaches some other device. Do locators
timeout?

Tom

> Beyond that we are getting into operational practices for mobile operators,
> which are not the topic of this discussion.
>
> Yours,
> Joel
>
>
>>>>> From
>>>>> data
>>>>> provided in a short email would probably be a disservice both to ILNP
>>>>> and
>>>>> to
>>>>>>> as to enable the use of effective and scalable IP routing to reach
>>>>>>> the
>>>>>>> UE
>>>>>>>> On Tue, Jun 6, 2017 at 9:34 AM, Joel M. Halpern
>>>>>>>> <[email-masked]>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> assign
>>>>>>>>> For something that is a single device, like a UE< it is even
>>>>>>>>> simpler
>>>>>>>>> to
>>>>>>>>>> Administrative Requests:
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>>>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 6 Jun 2017 23:48:51 -0400

Huh?  The ICMP is sent several times, specifically because of loss. 
This, and the related behaviors are discussed in the ILNP RFCs.
If all of them get lost, then communication gets lost.  Some other 
device using the old full locator (the 12 bits in isolation are not 
meaningful, nor are they analyzed separately by anything.  They were 
just an example of an allocation size for the eNodeB creating /64 
locators for the UE, as required by 3GPP) may receive IP packets, but 
they will be discarded.  They will not be considered part of the same 
session.

There are ways to make ti more robust, but then I would be moving the 
goal-posts, since those are not part of the ILNP RFCs.

Yours,
Joel