Skip to main content

Host Address Availability Recommendations
RFC 7934

Yes

Alvaro Retana
(Alia Atlas)
(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.

Alvaro Retana Yes

(Alexey Melnikov; former steering group member) (was No Objection) Yes

Yes (2016-05-03 for -06)
This is a well written document which argues well for assigning multiple IPv6 addresses per host.

(Alia Atlas; former steering group member) Yes

Yes (for -06)

                            

(Alissa Cooper; former steering group member) Yes

Yes (2016-05-03 for -06)
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?

(Ben Campbell; former steering group member) Yes

Yes (2016-05-03 for -06)
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 steering group member) Yes

Yes (for -06)

                            

(Mirja Kühlewind; former steering group member) Yes

Yes (for -06)

                            

(Spencer Dawkins; former steering group member) (was No Objection) Yes

Yes (for -06)

                            

(Suresh Krishnan; former steering group member) Yes

Yes (2016-05-03 for -06)
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 steering group member) Yes

Yes (for -06)

                            

(Deborah Brungard; former steering group member) No Objection

No Objection (for -06)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (2016-05-04 for -06)
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 steering group member) No Objection

No Objection (2016-05-03 for -06)
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 steering group member) No Objection

No Objection (2016-05-04 for -06)
(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.)