Host Address Availability Recommendations
RFC 7934

Note: This ballot was opened for revision 06 and is now closed.

(Alia Atlas) Yes

(Ben Campbell) Yes

Comment (2016-05-03 for -06)
No email
send info
While I am afraid the NAT66 cats are forever out of their bag, I am still glad to see this draft.

Section 7: I _think_ the point of this section is to suggest that we cannot reasonably estimate an upper limit. But if it says that explicitly, I missed it. (I fear a careless reader will walk away thinking "20" is a good limit)

Section 8: s/RECOMMENDED to not impose a hard limit/NOT RECOMMENDED to impose a hard limit/

Alissa Cooper Yes

Comment (2016-05-03 for -06)
No email
send info
Section 3: s/which is only available in 3GPP release 10/which has been made available as of 3GPP release 10/

Section 9.1: 
- May be better not to presume that operators do things "to avoid liability" - I don't think that particular sentence is necessary here.
- I was surprised not to see a note here about interaction between this kind of host tracking and MAC address randomization, which I assume makes tracking harder independently of the whether the recommendations in this document are followed. But is it not discussed because operators who feel they need these kind of logs also prohibit MAC randomization?

(Spencer Dawkins) (was No Objection) Yes

(Joel Jaeggli) Yes

Suresh Krishnan Yes

Comment (2016-05-03 for -06)
No email
send info
Section 3:

* What is the term ePDG being used here? Can you please add a reference? The well known term in mobile networks is Evolved Packet Data Gateway that is used for IPsec tunnel termination. That does not seem to make sense here.

* Maybe worth adding a reference to RFC7278 (64share) here as an example for "Extending the network (e.g., "tethering")."

s/which is only available in 3GPP release 10/which is only available in 3GPP release 10 onwards/

Section 4:

It is not clear what this bullet means. Can you clarify?

"  o  Uncertainty, because it is not known in advance if a particular
      operation function will be available."

Mirja K├╝hlewind Yes

(Terry Manderson) Yes

Alexey Melnikov (was No Objection) Yes

Comment (2016-05-03 for -06)
No email
send info
This is a well written document which argues well for assigning multiple IPv6 addresses per host.

Alvaro Retana Yes

(Jari Arkko) No Objection

Comment (2016-05-04 for -06)
No email
send info
I have followed the discussion between Roni Even (Gen-ART reviewer) and Lorenzo:

> The intent here is to say that while the DHCPv6 PD RFC uses the words 
> "requesting router" to denote the DHCP client, is nothing in DHCPv6 PD 
> itself that requires the PD client to be a router (where, in IPv6, the term
> "router" is defined in RFC2460).

> So - even though the DHCPv6 PD RFC uses the term "requesting router", a 
> host can use DHCPv6 PD to receive a prefix as well. The host can pick some 
> addresses for that prefix for its own use, originate/terminate packets on 
> those addresses, and not forward packets addressed to any of the other
> addresses in the prefix.

Personally, I think it would perhaps useful to consider a slight reformulation of the text, given that for things like tethering or virtual machines, hosts essentially become routers.

Deborah Brungard No Objection

(Stephen Farrell) No Objection

Comment (2016-05-04 for -06)
No email
send info
(I'm getting a bit outside my area of expertise here, but
since I've been playing about with IPv6 recently and am not
shy about asking silly questions... :-)

- I think you're missing one other reason why people
allocate /128's - in a hosting/VPS environment, the hoster
might want to avoid VPS's that originate spam using many
different source addresses over time so as to attempt to
avoid IP address based (bad) reputation accruing to their
outbound spam. Personally, I think associating such
reputation scores with IPv6 prefixes or addresses is a bit
dodgy, but this is I think something that is done in the
wild, (no idea how frequently) so would be worth a mention.
If you have good arguments as to why such a scheme is a bad
idea, that'd be good to include as well.

- I was a bit surprised to not see any mention here of
ULAs. I've seen one DHCPv6 setup where my laptop was
assigned a ULA with a very long lease in the hope of always
having that connectivity to local systems that aren't all
on the link. But having that plus real global addresses
caused glitches as (I think) my OS (ubuntu) wasn't sure
which of the addresses to use as the source for what.
While I didn't explore what was going on there (I just
zapped the lease:-), do you need to say how to handle cases
where one has both real global and ULAs on an interface? 

- I would have liked if you had said that, other things
being equal, OSes SHOULD prefer to use privacy addresses as
the source address or as a default. Is there a reason to
not say that? (Just wondering, I'm not trying to strongly
argue that you do.)

(Kathleen Moriarty) No Objection

Comment (2016-05-03 for -06)
No email
send info
I think the Complexity mentioned in section 4 should be a security consideration since there are more opportunities for mistakes that lead to data leakage.