Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-01.txt

[Tore Anderson <[e-mail]>]

* Ted Lemon

> On Jul 28, 2015, at 2:36 PM, Brian E Carpenter <[e-mail]> wrote:
> > Not to mention encountering the problems with /120 mentioned
> > in RFC 7421, which include the problems of only having a /24 in
> > IPv4. We should be past that.
> 
> To be clear, I wasn’t proposing /120 prefixes, but the delegation
> of /120 prefixes as a way of delivering a chunk of contiguous
> addresses smaller than a /64, which I continue to think is
> impractical for Lorenzo’s use case.

I was thinking something along the same lines, and not agreeing the
draft's statement that DHCPv6-PD cannot cater for «"unlimited"
endpoints». My view was that the problem could be solved, e.g., in this
way:

- Device 1 receives a delegated (<=) /64 from ISP/network (either 3GPP
  or DHCPv6-PD), which it then chops up in (for example) 2^16 /80s
  which may be handed out using DHCPv6-PD to downstream devices or
  local software functions (which would includes including its own
  loopback interface, local containers/VMs, etc.)
- Any downstream device that receives an /80 from the above device
  chops it up in 2^16 /96s which in the same way may be handed out to
  downstream devices or local software functions.
- Any downstream device that receives a /96 from a device at the above
  level can chop it up in 2^16 /112s and use it in the same way.

This would facilitate "unlimited" endpoints, assuming all the endpoints
support DHCPv6-PD. It would preclude the use of SLAAC, though, as any
link prefixes would be >/64. (However, the use of global link prefixes
would not really be necessary in the first place, as all links could be
link-local only).

Anyway, after having discussed this with Lorenzo at IETF93 I realised
that this is not covered because it is considered an invalid
configuration: RFC3633 section 12.1 says «for each IA_PD the requesting
router assigns a subnet from each of the delegated prefixes to each of
the links to which the associated interfaces are attached» and RFC7421
section 1 describes how «a subnet prefix longer than 64 bits is outside
the current IPv6 specifications». Thus, assigning DHCPv6-PD for prefixes
longer than /64 is seen as an invalid network configuration, and thus
not discussed in the draft as a potential solution.

While I am not completely convinced of the validity of that argument (in
particular, I am not entirely convinced that RFC3633 section 12.1
actually *prohibits* a requesting router from assigning a smaller
than /64 chunk of addresses out of a delegated prefix to its loopback
interface for use with local traffic), I suppose the position is fair
enough and I do not intend to argue this point further.

That said, given that the draft is targeted at operators, I think it
would benefit from unequivocally stating that the use of prefixes (both
delegated and link) with lengths >/64 are considered invalid and any
solution involving them is therefore not being discussed - because when
I read the draft while wearing my operator hat only, I see that as a
solution that would actually work just fine from a technical point of
view. RFC 7421 section 4.3.2 appears to confirm I am not alone in this,
stating «DHCPv6 is in widespread use without any dependency on the /64
boundary».

Tore