Host Address Availability Recommendations
draft-ietf-v6ops-host-addr-availability-07
Yes
(Alia Atlas)
(Alvaro Retana)
(Joel Jaeggli)
(Mirja Kühlewind)
(Spencer Dawkins)
(Terry Manderson)
No Objection
(Deborah Brungard)
Note: This ballot was opened for revision 06 and is now closed.
Alexey Melnikov Former IESG member
(was No Objection)
Yes
Yes
(2016-05-03 for -06)
Unknown
This is a well written document which argues well for assigning multiple IPv6 addresses per host.
Alia Atlas Former IESG member
Yes
Yes
(for -06)
Unknown
Alissa Cooper Former IESG member
Yes
Yes
(2016-05-03 for -06)
Unknown
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?
Alvaro Retana Former IESG member
Yes
Yes
(for -06)
Unknown
Ben Campbell Former IESG member
Yes
Yes
(2016-05-03 for -06)
Unknown
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/
Joel Jaeggli Former IESG member
Yes
Yes
(for -06)
Unknown
Mirja Kühlewind Former IESG member
Yes
Yes
(for -06)
Unknown
Spencer Dawkins Former IESG member
(was No Objection)
Yes
Yes
(for -06)
Unknown
Suresh Krishnan Former IESG member
Yes
Yes
(2016-05-03 for -06)
Unknown
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."
Terry Manderson Former IESG member
Yes
Yes
(for -06)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -06)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2016-05-04 for -06)
Unknown
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.
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2016-05-03 for -06)
Unknown
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.
Stephen Farrell Former IESG member
No Objection
No Objection
(2016-05-04 for -06)
Unknown
(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.)