Re: draft-bourbaki-6man-classless-ipv6-00

[Tom Herbert <[e-mail]>]

On Fri, Jun 2, 2017 at 10:51 PM, Lorenzo Colitti <[e-mail]> wrote:
> On Jun 3, 2017 13:51, "Tom Herbert" <[e-mail]> wrote:
>
>> This should read: "The phone enables bridging. All the devices behind it
>> share the /64."
>
> Which allows the phone to bridge 2^64 devices! I don't understand why
> my phone needs a /64. This is an impediment to being about to use
> Identifier Locator Address (ILA) meaningfully in carrier networks.
>
>
> ILA provides mobility by forcing mobile entities to be numbered within 64
> bits instead of 128.
>
I would point out that RFC7421 includes ILNP as a motivation for a
/64, but this argument is not a valid rationale for assigning /64 to
mobile devices. Mobile devices need to be assigned identifiers not
locators.

> That makes sense in a datacenter where the numbers of locators is limited
> and multiple identifiers often share a given locator, but it's extremely
> inefficient in a network where everything is point-to-point like today's
> subscriber and mobile networks.
>
I disagree. In a datacenter we have VMs that are mobile entities and
locators that are physical hosts. In a mobile network its the devices
themselves that are the mobile entities and the point of attachment,
e.g. base stations, that are the locators. The two cases are
isomorphic. So in order for identifier/locator split to work it should
be the base stations that have a /64 and the mobile devices that would
be an identifier. The impediment here is giving each low end device a
/64. If they were given a /96 or a /104 we could do a productive
identifier/locator split for mobility.

> When everything is point-to-point, identifiers can never share a locator and
> ILA effectively reduces the size of the address space from 128 bits to 64,
> reducing the number of addressable devices by 2e19. That's a spectacularly
> bad deal compared to the alternative, which is a few bytes of encap
> overhead.

How much of the /64 space that is being assigned to end devices is
being used? Unless it's more than some 0.00000...% that seems like the
spectacularly bad deal to me and the thing that is reducing that
Internet address space down to sixty-four bits. Forcing this
assignment precludes us from taking advantage of the incredibly large
address space with techniques like identifier/locator split. The only
recourse that we have is to use encapsulation which means another
forty bytes of header, another header to process, and makes this
solution no
different than what we can do in IPv4. The irony of the last point is
not lost, /64 is forcing us to implement mobility just like we'd do in
IPV4.

Tom