Unique IPv6 Prefix per Host
RFC 8273
Note: This ballot was opened for revision 07 and is now closed.
(Suresh Krishnan) (was Discuss) Yes
Comment (2017-09-13 for -08)
No email
send info
send info
Thanks for addressing my DISCUSS and COMMENTs.
Warren Kumari Yes
Deborah Brungard No Objection
(Ben Campbell) No Objection
Comment (2017-10-11 for -12)
No email
send info
send info
Thanks for addressing my previous comments.
(Benoît Claise) No Objection
Comment (2017-10-12 for -12)
No email
send info
send info
Two nits: - Lorenzo: https://mailarchive.ietf.org/arch/msg/v6ops/EbF-7q17N9qy8N4KV2mOMuMY9YY (emphasise the multi addressing) - Tim: https://mailarchive.ietf.org/arch/msg/v6ops/Fu-b--IA3NkbgvmXET1tygeF920 (should 7217 be mentioned not just old 4862 SLAAC, and on consistency between 8106 and stateless DHCPv6) I trust the responsible AD's judgement to evaluate if those editorial changes are important enough. Regards, Benoit
Alissa Cooper (was Discuss) No Objection
Comment (2017-10-16)
No email
send info
send info
Thanks for addressing my DISCUSS point.
(Spencer Dawkins) No Objection
Comment (2017-08-15 for -07)
No email
send info
send info
One nit: Please consider moving Benefits of unique IPv6 prefix over a unique IPv6 address from the service provider include improved subscriber isolation and enhanced subscriber management. to the first paragraph of the Abstract. I’m assuming that this explains the “needs that have arisen” in the first sentence of the Abstract, of course.
(Mirja Kühlewind) No Objection
Comment (2017-08-14 for -07)
No email
send info
send info
To me this seems approriate for BCP; I'm saying this because this was mentioned in the shepherd-write-up as it was brought up by the gen-art review. Please also consider the following comment from the gen-art review (Thanks Joel!): "The issue of status for the document (BCP vs Informational) is for the IESG to conclude. However, even if it is a BCP, as I understand the purpose, this document is intended to describe the practices to be used when a provider has decided to deploy a /64 per host. The wording that is chosen throughout the document makes it appear that the underlying decision about such a deployment is also a recommended practice." I agree that wording could be made clearer here!
(Alexey Melnikov) No Objection
Comment (2017-08-12 for -07)
No email
send info
send info
Radius should have an informative reference on first use.
(Kathleen Moriarty) No Objection
Comment (2017-08-15 for -07)
No email
send info
send info
Thank you for addressing the SecDir review: https://mailarchive.ietf.org/arch/msg/secdir/wWp_0vlmsz7Ss-nowjhehYImOeg
(Eric Rescorla) No Objection
Comment (2017-08-15 for -07)
No email
send info
send info
Document: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt I found the discussion of the shared network medium a bit confusing. As I understand it, the idea is that if we are on a shared network and we have the same prefix, I might try to send to you directly. What you want to do is make that not happen by having each node have a separate prefix. Correct? If so, perhaps promote this bullet, and also have it describe the problem and why this provides a solution: o Two devices (subscriber/hosts), both attached to the same provider managed shared network should only be able to communicate through the provider managed First Hop Router It's a bit unclear to me how much you are saying that something is current practice versus how much you are recommending it. For instance, the abstract reads more like what you would expect for PS. This document outlines an approach utilising existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). Benefits of unique IPv6 prefix over a unique IPv6 address from the service provider include improved subscriber isolation and enhanced subscriber management. But then S 4 seems to be documenting: The IPv6 RA flags used for best common practice in IPv6 SLAAC based Provider managed shared networks are: The use of a unique IPv6 prefix per UE adds an additional level of protection and efficiency as it relates to how IPv6 Neighbor Discovery and Router Discovery processing. Since the UE has a unique IPv6 prefix all traffic by default will be directed to the First Hop provider router. Further, the flag combinations documented above maximise the IPv6 configurations that are available by hosts including the use of privacy IPv6 addressing. It's not quite clear to me why unique prefixs are needed here if people set L=0. Is it that people ignore L=0? Finally, I'm a bit confused about how to read this text about the L=0 bit in cases where I have multiple devices rather than just one at the customer prem. Say I have a topology with a home router and devices behind it. I.e., Service Provider | | Customer Router | +-----------+-----------+ | | | Host 1 Host 2 Host 3 I assume what happens here is that the router gets prefix X, assigns itself XY, and then the Hosts get XA, XB, XC, etc, a la 7278. Is that right? If so, my question is about packets coming into the Router from the SP, which have (say) XA. The text about the L-flag suggests that the router should send them back to the gateway, but that's clearly not right. What am I missing?