Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt

[Mark Smith <[e-mail]>]

On 4 Aug 2017 12:47, "DY Kim" <[e-mail]> wrote:

> Taken.

> A follow-on question:

> Assume the site under my management purview is assigned a /48 prefix from an upstream provider. Can I apply this BCP to the devices in my site?


No reason you couldn't, how you use those 64k /64s is up you and would
be hidden from the provider.

I can imagine some sites might have a mix of per-host /64s as well as
a number of /64s with multiple hosts (that is, today's model), perhaps
where some of the devices are unlikely to benefit from having their
own /64 e.g., low powered IoT/sensor devices perhaps. A residential
network might have a mix.


> I think that’s at least technically possible. And I don’t see a text in the doc which prevents me from doing that on my own autonomous decision and responsibility. Right?

Even if there was text in the document that stated it was prohibited,
I don't see how it could be policed, or be worth paying the cost of
developing a system to try to police it.


Regards,
Mark.




> On 4 Aug 2017, at 11:39, Mark Smith <[e-mail]> wrote:
>
> On 4 August 2017 at 11:53, DY Kim <[e-mail]> wrote:
>> In the 2nd para of Sec. 4, it reads:
>>
>> “… a Unique IPv6 prefix (currently a /64 prefix)…”
>>
>> Assuming that there’d be at some place upwards where a /48 prefix would be
>> present, which prefix length is up to a common practice for ISPs in
>> assigning a prefix to a site, does the above spec means:
>>
>> o the maximum number of devices that the proposed scenario can accommodate
>> is 64K (2**16; 64 - 48 = 16)?
>>
>
> (Not speaking on the authors behalf)
>
> If you only received a /48 for your site, then yes, that would be the
> upper limit on how many devices this method supported.
>
> However, the scenario being described is one of a service provider,
> and they will get at least a /32 from their RIR, meaning in theory the
> maximum number of hosts they can support is 4 billion (!). They could
> get larger than /32 if they needed to if it became too small.
>
> In this scenario a "site" is really the individual host, rather than a
> boundary of a group of subnets at a site. /48 or /56 are common
> aggregation boundaries for a multi-subnet site, so they don't really
> apply here. The service provider could internally aggregate the /64s
> at any where they need to between e.g. /32 and /63 to suit their
> routing protocol scaling.
>
> So in short, /48 is not constraining this solution because /48 doesn't apply.
>
> Regards,
> Mark.