Re: [v6ops] I-D Action: draft-templin-v6ops-pdhost

["Templin, Fred L" <[e-mail]>]

Hi Dusan,

There is a big difference. Hosts that receive prefix delegations have to be active
participants in the prefix delegation and maintenance procedures, e.g., as is the
case for DHCPv6 PD clients. This requires the host to implement some functions
beyond what is called for in vanilla RFC4861.
[[Dusan]] These ‘some’ functions on the hosts need to be defined in draft-templin-v6ops-pdhost. They are not so far. Without them, the draft is incomplete.

I think we are going to have to disagree on this point. ‘draft-templin-v6ops-pdhost’
is an informational document that tells how hosts accommodate existing prefix
advertisement/delegation processes. It is therefore outside the scope for it to
specify a new host/router protocol for coordinating prefix delegations via IPv6
ND messaging.

In the first case, hosts that are active participants in prefix delegation procedures
are aware that the prefix they are receiving is a delegated
[[Dusan]] How?

An example that is given is DHCPv6 PD, as specified in RFCs 3315 and 3633.
There may be other examples in the future but we only need one example
for the time being.

DAD over the upstream interface. In the latter case, vanilla rfc4861 hosts that are
passive recipients of an individual prefix have no idea that the prefix has been
reserved for their exclusive use and so must do DAD over the upstream interface.
[[Dusan]] This is good. But the whole protocol for the host is missing in the draft. The messaging and how the host know they are assigned the ‘delegated’ prefix is missing.

See above – this is an informational document not seeking to establish a
new standard for an IPv6 ND-based prefix delegation messaging service.

For host with ‘delegated’ prefixes, if the host will be able to know they don’t need to do DAD on the upstream interface, they will also know they don’t need to do the address resolution on the same interface. If the ‘delegated’ prefix provides other benefits, like those discussed for the ‘individual’ prefixes (i.e. on-link hosts on different VLANs send packets to the first hope router, the first hope destination is always a router that provides security services, …), those benefits should be referenced.

I think the document is already clear on the benefits for delegated prefixes. Most
importantly, addresses from delegated prefixes can be assigned to interfaces other
than the upstream interface whereas addresses from individual prefixes can only
be assigned to the upstream interface.

The draft should also mention that the ‘individual’ prefix does not provide the same benefits because the hosts don’t know they are assigned the individual prefixes. If the host know they are using the individual prefix, they would not need to do DAD and the address resolution. If the ‘individual’ prefixes require the same maintenance procedure by host as ‘delegated’ prefixes, then there is no difference between the two. So far I don’t see why ‘delegated’ prefixes need to be managed differently than ‘individual’ prefixes. If we prove the ‘individual’ and ‘delegated’ prefixes on the hosts are:

-          managed the same way, and

-          provide the same benefits
we should bundle them on host into one.

The whole point of distinction is whether the host needs to implement some functions
beyond basic IPv6 ND. For delegated prefixes, the host needs to implement prefix
delegation functions such as specified In RFC 3315/3633; for individual prefixes, the
host simply does basic IPv6 ND. Note that the host would benefit from engaging in
a prefix delegation service (e.g., DAD avoidance) but we still need to accommodate
unmodified vanilla RFC4861-complaint hosts.

It should be mentioned somewhere that routers should be configured to assign one of the prefixes, based on the local network needs. There might be special cases when two prefix types might be needed.

We are going around in circles, as I think I have already said pretty much
everything that I just repeated above and I don’t see the need for any further
changes to the draft. The main thing is that I don’t want to expand the scope
of the draft to try to accommodate the definition of a new protocol. Some
other future document that might specify a new prefix delegation protocol
would have to do that.

Thanks - Fred

From: Mudric, Dusan (Dusan) [mailto:[e-mail]]
Sent: Tuesday, October 24, 2017 7:01 AM
To: Templin, Fred L <[e-mail]>; Lorenzo Colitti <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: RE: [v6ops] I-D Action: draft-templin-v6ops-pdhost

Hi Fred,

Please find inlined.

Thanks,
Dusan.

From: Templin, Fred L [mailto:[e-mail]]
Sent: Monday, October 23, 2017 5:38 PM
To: Mudric, Dusan (Dusan); Lorenzo Colitti
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [v6ops] I-D Action: draft-templin-v6ops-pdhost

Hi Dusan,

[[Dusan]] To me:

-          On hosts ‘individual’ and ‘delegated’ prefixes provide the same benefits and there is no difference between the two

There is a big difference. Hosts that receive prefix delegations have to be active
participants in the prefix delegation and maintenance procedures, e.g., as is the
case for DHCPv6 PD clients. This requires the host to implement some functions
beyond what is called for in vanilla RFC4861.
[[Dusan]] These ‘some’ functions on the hosts need to be defined in draft-templin-v6ops-pdhost. They are not so far. Without them, the draft is incomplete.
On the other hand, hosts that receive
individual prefixes follow the basic procedures in RFC4861 which do not call for
any explicit prefix delegation and maintenance procedures on the part of the host.

In the first case, hosts that are active participants in prefix delegation procedures
are aware that the prefix they are receiving is a delegated
[[Dusan]] How?
one and need not do
DAD over the upstream interface. In the latter case, vanilla rfc4861 hosts that are
passive recipients of an individual prefix have no idea that the prefix has been
reserved for their exclusive use and so must do DAD over the upstream interface.
[[Dusan]] This is good. But the whole protocol for the host is missing in the draft. The messaging and how the host know they are assigned the ‘delegated’ prefix is missing.

For host with ‘delegated’ prefixes, if the host will be able to know they don’t need to do DAD on the upstream interface, they will also know they don’t need to do the address resolution on the same interface. If the ‘delegated’ prefix provides other benefits, like those discussed for the ‘individual’ prefixes (i.e. on-link hosts on different VLANs send packets to the first hope router, the first hope destination is always a router that provides security services, …), those benefits should be referenced.

The draft should also mention that the ‘individual’ prefix does not provide the same benefits because the hosts don’t know they are assigned the individual prefixes. If the host know they are using the individual prefix, they would not need to do DAD and the address resolution. If the ‘individual’ prefixes require the same maintenance procedure by host as ‘delegated’ prefixes, then there is no difference between the two. So far I don’t see why ‘delegated’ prefixes need to be managed differently than ‘individual’ prefixes. If we prove the ‘individual’ and ‘delegated’ prefixes on the hosts are:

-          managed the same way, and

-          provide the same benefits
we should bundle them on host into one.

It should be mentioned somewhere that routers should be configured to assign one of the prefixes, based on the local network needs. There might be special cases when two prefix types might be needed.

I don’t think the document needs to say anything else; all other details are in the
references (RFC3315/RFC3633/RFC4861).
[[Dusan]] But you stated that the existing RS/RA is not good enough to manage the prefix. This statement does not define how the prefix should be managed:

RFCs 3315/3633 define how prefixes delegated by DHCPv6 are managed. RFC4861
has no corresponding prefix management procedures for prefixes discovered via
IPv6 ND. Those procedures are not written down anywhere and AFAICT have not
even been invented yet.

“1) the communication of a prefix from a delegating router to a requesting router, 2) a representation of the
prefix in the delegating router's routing table, and 3) a control messaging service
between the delegating and requesting  routers to maintain prefix lifetimes”.
If there is more to RFC4861, it should be defined here.

There is more to it than just RFC4861. But, it is out of scope for this document.

Thanks - Fred

From: Mudric, Dusan (Dusan) [mailto:[e-mail]]
Sent: Monday, October 23, 2017 10:25 AM
To: Templin, Fred L <[e-mail]<mailto:[e-mail]>>; Lorenzo Colitti <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [v6ops] I-D Action: draft-templin-v6ops-pdhost

Hi Fred,

Please see inligned.

Thanks,
Dusan.

From: Templin, Fred L [mailto:[e-mail]]
Sent: Friday, October 20, 2017 2:56 PM
To: Mudric, Dusan (Dusan); Lorenzo Colitti
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [v6ops] I-D Action: draft-templin-v6ops-pdhost

Hi Dusan,

Changing the title. This discussion is about draft-templin-v6ops-pdhost.

Sure.

General comment: draft-templin-v6ops-pdhost needs to define the coexistence (or not) of ‘shared’, ‘individual’ and ‘delegated’ prefixes. Which of the three can be assigned at the same time and what happens then?

IPv6 hosts may receive multiple prefixes the same as they may receive multiple
addresses. It does not matter which combination of prefix types they receive;
hosts simply do the expected thing according to each prefix type. This is simply
by nature of RFC4861 and RFC3315/RFC3633, and I don’t see a need to say
anything more in this document – unless you would care to suggest text?

[[Dusan]] To me:

-          On hosts ‘individual’ and ‘delegated’ prefixes provide the same benefits and there is no difference between the two

-          If individual/shared prefix is assigned, there is obviously a need for it (i.e. to manage the host security by the router or direct packets on different VLANs to the router). Even though an administrator controls the prefix assignments, a host should prefer individual/delegated addresses over the shared addresses, if both are assigned.

For more, please see inlined.

OK.

Certainly. But, note that that document is now expired.
[[Dusan]] Meaning all the discussion about the advantages of ‘individual’ and ‘delegated’ prefixes was not relevant? In my opinion, if there are benefits for hosts, host should use them.

My belief is that the authors of ‘pioxfolks’ will at some point want to resurrect the
document and submit an update. So, I consider that document as still relevant.
I cannot speak for the authors, however.

[[Dusan]] The draft does talk about “strong host” model. It should define the behavior for the “strong host”.

Strong host / weak host are as defined in RFC1122 and RFC8028. It only considers
the manner in which hosts receive or discard packets arriving on an interface. In
the strong host model, a packet arriving on an interface is only accepted if the
destination address matches an address assigned to the interface. In the weak host
model, a packet is accepted even if the destination address does not match an
address assigned to the interface.

The manner in which shared, individual and delegated prefixes are coordinated is
not related to either the strong vs weak models, so I don’t think there is anything
more to say in the document.

1) the communication of a prefix from a delegating router to a requesting router, 2) a representation of the
prefix in the delegating router's routing table, and 3) a control messaging service
between the delegating and requesting  routers to maintain prefix lifetimes”.
Is all of this applicable to the “strong hosts”? If not, what should the strong hosts do? How should they manage the prefix?

Prefix management is independent of strong vs. weak; it is the same in both cases.

Even for the routers, the statement is generic and in Introduction. If you have more specific mechanism to manage the prefix, it should be defined further down in the document.

I don’t think the document needs to say anything else; all other details are in the
references (RFC3315/RFC3633/RFC4861).
[[Dusan]] But you stated that the existing RS/RA is not good enough to manage the prefix. This statement does not define how the prefix should be managed:
“1) the communication of a prefix from a delegating router to a requesting router, 2) a representation of the
prefix in the delegating router's routing table, and 3) a control messaging service
between the delegating and requesting  routers to maintain prefix lifetimes”.
If there is more to RFC4861, it should be defined here.


Thanks - Fred

From: Mudric, Dusan (Dusan) [mailto:[e-mail]]
Sent: Friday, October 20, 2017 9:11 AM
To: Templin, Fred L <[e-mail]<mailto:[e-mail]>>; Lorenzo Colitti <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [v6ops] I-D Action: draft-templin-v6ops-pdhost

Hi Fred,

Changing the title. This discussion is about draft-templin-v6ops-pdhost.

General comment: draft-templin-v6ops-pdhost needs to define the coexistence (or not) of ‘shared’, ‘individual’ and ‘delegated’ prefixes. Which of the three can be assigned at the same time and what happens then?

For more, please see inlined.

Thanks,
Dusan.

From: Templin, Fred L [mailto:[e-mail]]
Sent: Friday, October 20, 2017 11:02 AM
To: Mudric, Dusan (Dusan); Lorenzo Colitti
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Dusan,

Responding to your comments:

Ah yes, your comment is related to ‘draft-pioxfolks-6man-pio-exclusive-bit’. That document
suggests an ‘X’ (“eXclusive”) bit added to the PIO flags.
[[Dusan]] So, the idea is already documented. Did not follow this discussion. Thanks for the reference.

Certainly. But, note that that document is now expired.
[[Dusan]] Meaning all the discussion about the advantages of ‘individual’ and ‘delegated’ prefixes was not relevant? In my opinion, if there are benefits for hosts, host should use them.
[[Dusan]] Can you please provide these host specific details in the draft-templin-v6ops-pdhost? I expected that RS/RA can do all DHCPv6 does: Request (RS)/Reply (RA)/Renew (RA)/Rebind (RA)/Release (RA)/Reconfigure (RA). If there is more to it, please describe in the draft-templin-v6ops-pdhost.
I am skeptical that RS/RA would be appropriate – at least not in the way you
are describing above. RA is the swiss army knife of IPv6 ND; it provides way
more information than would be appropriate for a prefix delegation exchange.
It might work to instrument NS/NA, e.g., similar to the way I have described
for Route Information Options in ‘draft-templin-6man-rio-redirect’, but I
don’t think the specification belongs in ‘pdhost’.
[[Dusan]] The draft does talk about “strong host” model. It should define the behavior for the “strong host”. In the introduction there is:
“1) the communication of a prefix from a delegating router to a requesting router, 2) a representation of the
prefix in the delegating router's routing table, and 3) a control messaging service
between the delegating and requesting  routers to maintain prefix lifetimes”.
Is all of this applicable to the “strong hosts”? If not, what should the strong hosts do? How should they manage the prefix?

Even for the routers, the statement is generic and in Introduction. If you have more specific mechanism to manage the prefix, it should be defined further down in the document.
And, if the ‘exclusive’ bit for the delegated prefix is set, the host is no longer required to do the address resolution for the ‘individual’ prefixes:
“When a node receives a shared or individual prefix with "L=1" and has
a packet to send to an IPv6 destination within the prefix, it is
required to use the IPv6 ND address resolution function over the
upstream interface to resolve the link-layer address of a neighbor
that configures the address.
Can you further polish  this part please?
AFAICT, the specification of an IPv6 ND-based prefix delegation control message
service would be out of scope for the ‘pdhost’ document and might better appear
in the ‘pioxfolks’ draft. But, remember that DHCPv6 already specifies a way of
doing prefix delegation.

This is what is often known in IETF terms as a “tussle space” – a sorting out of
two or more approaches to accomplishing the same thing. IPv6 ND and DHCPv6
have been in a tussle for years, and this particular tussle is currently playing out
in the eye of a storm.

Thanks - Fred

From: Mudric, Dusan (Dusan) [mailto:[e-mail]]
Sent: Friday, October 20, 2017 7:28 AM
To: Templin, Fred L <[e-mail]<mailto:[e-mail]>>; Lorenzo Colitti <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Fred,

Please find inlined.

Thanks,
Dusan.

From: Templin, Fred L [mailto:[e-mail]]
Sent: Wednesday, October 18, 2017 4:32 PM
To: Mudric, Dusan (Dusan); Lorenzo Colitti
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Dusan,

[[Dusan]] The section 7 wording depends on the host H1 knowledge about the prefix type. If the host knows it is individual or delegated prefix, there is no need for ND DAD and address resolution on the upstream link. Since avoiding DAD and the address resolution is very important, we should have a mechanism in place to provide that knowledge to the hosts. I could not find the RFC that defines the prefix types. rfc3769 does not define the delegated prefix type. It just assumes the router knows if the prefix is assigned to it, it is the delegated prefix. If the delegated prefix is assigned to hosts, how they will know it is the delegated vs. individual prefix vs shared prefix? What are advantages of delegated prefixes over individual prefixes to hosts? Or, should the host have these two prefix types? Should these two prefixes be treated as the same type by hosts? One way or the other, hosts should know it is shared vs (individual/delegated) prefix and take the advantage of the (individual/delegated) prefixes. For example, https://tools.ietf.org/html/rfc4861#section-4.6.2<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4861-23section-2D4.6.2&d=DwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=BoYLHzx6Y_ftZaZNIXHlyP821J99H7FX_pp9bp8lloA&s=Z9djxUOB-Betmy0ioHjc74Gn-ctR0dQX31EZD4ys8cE&e=> can define a reserved bit to distinguish between the two prefixes, shared vs (individual/delegated). If the bit is set (meaning (individual/delegated) prefix), don’t do DAD and address resolution.

Ah yes, your comment is related to ‘draft-pioxfolks-6man-pio-exclusive-bit’. That document
suggests an ‘X’ (“eXclusive”) bit added to the PIO flags.
[[Dusan]] So, the idea is already documented. Did not follow this discussion. Thanks for the reference.
The procedures for defining a new
bit in the PIO flags field are given in ‘draft-troan-6man-ndpioiana’.

But, more is required than just informing the host that the prefix has been delegated.
‘draft-templin-v6ops-pdhost’ says that prefix delegation entails: “1) the communication
of a prefix from a delegating router to a requesting router, 2) a representation of the
prefix in the delegating router's routing table, and 3) a control messaging service
between the delegating and requesting  routers to maintain prefix lifetimes”.

So, even if the router has a way to tell the host that the prefix is delegated (e.g., via
an ‘X’ bit in the PIO flags) there still needs to be a control messaging service between
the host and the router, and (in the case of IPv6 ND) simple RS/RA messaging is not
sufficient. In the case of DHCPv6 PD, there are a set of control messages including
Request/Reply/Renew/Rebind/Release/Reconfigure (the “six R’s” of PD) that are
explicitly provided for that purpose.
[[Dusan]] Can you please provide these host specific details in the draft-templin-v6ops-pdhost? I expected that RS/RA can do all DHCPv6 does: Request (RS)/Reply (RA)/Renew (RA)/Rebind (RA)/Release (RA)/Reconfigure (RA). If there is more to it, please describe in the draft-templin-v6ops-pdhost.
And, if the ‘exclusive’ bit for the delegated prefix is set, the host is no longer required to do the address resolution for the ‘individual’ prefixes:
“When a node receives a shared or individual prefix with "L=1" and has
a packet to send to an IPv6 destination within the prefix, it is
required to use the IPv6 ND address resolution function over the
upstream interface to resolve the link-layer address of a neighbor
that configures the address.
Can you further polish  this part please?

Thanks - Fred

From: Mudric, Dusan (Dusan) [mailto:[e-mail]]
Sent: Wednesday, October 18, 2017 9:46 AM
To: Templin, Fred L <[e-mail]<mailto:[e-mail]>>; Lorenzo Colitti <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Fred,

As always, thanks for your help. Please see inline for the new comment.

Regards,
Dusan.

From: Templin, Fred L [mailto:[e-mail]]
Sent: Tuesday, October 17, 2017 5:54 PM
To: Mudric, Dusan (Dusan); Lorenzo Colitti
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Dusan,

I don’t expect the H1 host to send a packet to outgoing interface using P1 based address. ‘L=1’ becomes irrelevant for the individual prefix. ND on the hosts is never needed. Did I miss something? What is the use case for this statement?
“When a node receives a shared or individual prefix with "L=1" and has
a packet to send to an IPv6 destination within the prefix, it is
required to use the IPv6 ND address resolution function over the
upstream interface to resolve the link-layer address of a neighbor
that configures the address.

Would it satisfy the concern if I were to remove the words “shared” and “individual”
from the above statement, i.e., change it to:

  “When a node receives a Prefix Information Option in a Router Advertisement with “L=1”
   and has a packet to send to an IPv6 destination within the prefix, …”

[[Dusan]] Good point. Thanks. Is there a way for the host to figure out this is an individual prefix and there is no need for DAD?

The only way for the host to know that the prefix is intended for its own exclusive
use (and hence no need for DAD) would be if the host were to engage in some sort
of prefix delegation messaging. This means that the host would need some additional
functionality beyond just RFC4861. But then, it would be a delegated prefix and not
an individual prefix.

[[Dusan]] The section 7 wording depends on the host H1 knowledge about the prefix type. If the host knows it is individual or delegated prefix, there is no need for ND DAD and address resolution on the upstream link. Since avoiding DAD and the address resolution is very important, we should have a mechanism in place to provide that knowledge to the hosts. I could not find the RFC that defines the prefix types. rfc3769 does not define the delegated prefix type. It just assumes the router knows if the prefix is assigned to it, it is the delegated prefix. If the delegated prefix is assigned to hosts, how they will know it is the delegated vs. individual prefix vs shared prefix? What are advantages of delegated prefixes over individual prefixes to hosts? Or, should the host have these two prefix types? Should these two prefixes be treated as the same type by hosts? One way or the other, hosts should know it is shared vs (individual/delegated) prefix and take the advantage of the (individual/delegated) prefixes. For example, https://tools.ietf.org/html/rfc4861#section-4.6.2<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4861-23section-2D4.6.2&d=DwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=BoYLHzx6Y_ftZaZNIXHlyP821J99H7FX_pp9bp8lloA&s=Z9djxUOB-Betmy0ioHjc74Gn-ctR0dQX31EZD4ys8cE&e=> can define a reserved bit to distinguish between the two prefixes, shared vs (individual/delegated). If the bit is set (meaning (individual/delegated) prefix), don’t do DAD and address resolution.

The prefix type knowledge might help for the further security improvements. For example, a host would know it should not add NCE for the addresses that start with the prefix delegated to the host. I am sure there will be more ideas around it.

[[Dusan]] Ok. Can you add a note please in the security section about the impact of delegated and individual prefixes on the address privacy? That will help decide whether to use “the prefix as on-link” when stable or temporary addresses are needed.

Sure, I will add something.

About your other points, I think they are now fixed in the -15 modulo the discussion
points above. If you see something in the -15 that still looks broken let me know so
I can fix it in a -16.

Thanks - Fred



From: Mudric, Dusan (Dusan) [mailto:[e-mail]]
Sent: Tuesday, October 17, 2017 1:50 PM
To: Templin, Fred L <[e-mail]<mailto:[e-mail]>>; Lorenzo Colitti <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Fred,

Please see inlined

Thanks,
Dusan.

From: Templin, Fred L [mailto:[e-mail]]
Sent: Tuesday, October 17, 2017 3:36 PM
To: Mudric, Dusan (Dusan); Lorenzo Colitti
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Dusan,

Question about the first sentence in section 7:
“When a node receives a shared or individual prefix with "L=1”
Why would the individual prefix have “L=1”?

What makes an individual prefix an individual prefix is merely the fact that
the router advertises the prefix to exactly one node and does not advertise
it to any other nodes. In that case, the setting or not setting of the ‘L’ bit is
up to the router and beyond the scope of what we are trying to convey in
this document.
[[Dusan]] The router should never assign more than one individual prefix to more than one host. When sending a packet from H1 to a an on-link destination H2, using an individual prefix P2, the H1 host should not have the P2 prefix in its prefix list. Since the prefix list has only one prefix P1 (this is my assumption; suggest defining this behavior for delegated prefix too; the node needs to know if it is possible to get other prefixes if it is assigned individual or delegated prefix; if router can assign a combo of prefixes, this needs to be defined), the H2 destination is considered off-link and the packet is sent to the first hop router.

I don’t expect the H1 host to send a packet to outgoing interface using P1 based address. ‘L=1’ becomes irrelevant for the individual prefix. ND on the hosts is never needed. Did I miss something? What is the use case for this statement?
“When a node receives a shared or individual prefix with "L=1" and has
a packet to send to an IPv6 destination within the prefix, it is
required to use the IPv6 ND address resolution function over the
upstream interface to resolve the link-layer address of a neighbor
that configures the address.

I don’t understand why https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-12#section-4<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dv6ops-2Dunique-2Dipv6-2Dprefix-2Dper-2Dhost-2D12-23section-2D4&d=DwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=oXYlcovo9etCYLf5ReCeD4gdzkL1wdDovM5mC0M92Ag&s=IVnlMA0rEI49jpUNYU_SegkbY7MLEuGchNU2HrvwcdM&e=> requires DAD for the individual prefix:
   Since the
   address is composed by the subscriber device itself, it will need to
   verify that the address is unique on the shared network.
If there is no node on the link with the individual prefix, why is DAD required?

My understanding is that an unmodified host that receives a prefix with “A=1; L=0”
will autoconfigure one or more addresses from the prefix and assign them to the
interface over which the prefix was received. But, since “L=0” in itself conveys
no indication as to whether the prefix is individual or shared, the host has to do
DAD under the assumption that other hosts may have received the same prefix.
[[Dusan]] Good point. Thanks. Is there a way for the host to figure out this is an individual prefix and there is no need for DAD?


[[Dusan]] I check the section 7. It only talks about the “on-link node” redirects. Can you please add something about the first hop router redirects (e.g. for a better route)?

Not sure I see a problem with the text as it is written. It already mentions the first hop
router as the one that would send any redirects.


Regarding the redirects, for a better security, can hosts have an option to ignore them? There are already out-of-band options to set the hosts to ignore redirects. Should that be mentioned in the security section?

Yes, certainly. Routers need not send redirects, and hosts need not listen to them.
That is the same as for any link. I can add something to Security Considerations.


[[Dusan]] Question about “For delegated prefixes and individual prefixes that are not considered on-link”. If the “the router delivers all packets that match the prefix to the unicast link-layer address of the node”, doesn’t this violate the address privacy in RFC4941?

It is the same consideration as for any router that receives a delegated prefix. The
routing system will unconditionally deliver all packets that match the prefix to the
router, and it is up to the router to drop the packet and (optionally) return DU
“address unreachable” if the address is not in use. If the address is in use, though,
the router will deliver the packet to the end system that configures the address
even for privacy addresses. That is just the way routers work.
[[Dusan]] Ok. Can you add a note please in the security section about the impact of delegated and individual prefixes on the address privacy? That will help decide whether to use “the prefix as on-link” when stable or temporary addresses are needed.


[[Dusan]] ping6 should go the first hope router on the upstream interface, without the address resolution. There is no another node assigned the same prefix. There is no need for the address resolution for 2001:db8:1:2::20.

You are right; I made a mistake in the -14 version of the document but it should now
be fixed in the -15. Can you check again to verify?
[[Dusan]] I think this needs to be changed. Please see the arguments above:
7.  IPv6 Neighbor Discovery Implications

   When a node receives a shared or individual prefix with "L=1" and has
   a packet to send to an IPv6 destination within the prefix, it is
   required to use the IPv6 ND address resolution function over the
   upstream interface to resolve the link-layer address of a neighbor
   that configures the address.
Even if “a neighbor that configures the address” is a router, the node should already know the router’s link layer address and there is no need for the address resolution.

Thanks - Fred

From: Mudric, Dusan (Dusan) [mailto:[e-mail]]
Sent: Tuesday, October 17, 2017 11:39 AM
To: Templin, Fred L <[e-mail]<mailto:[e-mail]>>; Lorenzo Colitti <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Fred,

Thanks for the updates.

Question about the first sentence in section 7:
“When a node receives a shared or individual prefix with "L=1”
Why would the individual prefix have “L=1”?

I don’t understand why https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-12#section-4<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dv6ops-2Dunique-2Dipv6-2Dprefix-2Dper-2Dhost-2D12-23section-2D4&d=DwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=oXYlcovo9etCYLf5ReCeD4gdzkL1wdDovM5mC0M92Ag&s=IVnlMA0rEI49jpUNYU_SegkbY7MLEuGchNU2HrvwcdM&e=> requires DAD for the individual prefix:
   Since the
   address is composed by the subscriber device itself, it will need to
   verify that the address is unique on the shared network.
If there is no node on the link with the individual prefix, why is DAD required?

For other comments, please find the responses inlined.

Thanks,
Dusan.

From: Templin, Fred L [mailto:[e-mail]]
Sent: Wednesday, October 11, 2017 5:35 PM
To: Mudric, Dusan (Dusan); Lorenzo Colitti
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Dusan,

Responses below:

Thanks - Fred

From: Mudric, Dusan (Dusan) [mailto:[e-mail]]
Sent: Wednesday, October 11, 2017 11:37 AM
To: Templin, Fred L <[e-mail]<mailto:[e-mail]>>; Lorenzo Colitti <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Fred,

Thanks for further clarifying the router and host behaviors.

Questions about the latest “-14” updates:


-          General questions:

o   Should the new definitions for the ‘individual prefix’ be in draft-ietf-v6ops-unique-ipv6-prefix-per-host document?


>  I cannot speak for that document.



o   In the Security section, can you add more about:

•  DAD security benefits (e.g. when a node does not use DAD, so it cannot be attached with DAD),

•  NCE security benefits (e.g. when a number of NCE entries is limited to one per advertised prefix, or so),


>  Certainly yes about these items.



•  Malicious redirects (e.g. when the redirect is not required, so a node cannot be attached with redirects), and

•  and rogue RAs?


>  Redirects and RAs are only accepted from the first-hop router. So, a malicious redirect

>  or RA would be one that spoofs the source address of the first-hop router. But, that

>  is a general link-layer security concern for IPv6 ND in general and not necessarily

>  specific to this document. Or, do you see it differently?

[[Dusan]] I check the section 7. It only talks about the “on-link node” redirects. Can you please add something about the first hop router redirects (e.g. for a better route)?



Regarding the redirects, for a better security, can hosts have an option to ignore them? There are already out-of-band options to set the hosts to ignore redirects. Should that be mentioned in the security section?



These clarifications will help define when nodes should not use DAD, redirect, …


>  My opinion is that a node should not do DAD unless it has to.



-          ‘individual prefix’






The router that advertises the prefix can consider the prefix as on-link or


not on-link. In the former case, the router performs address


resolution so that it only forwards those packets that match one


of the node's configured addresses.”


You introduced extra flexibility for the unique prefix. What is the motive for the on-link prefix, that requires extra address resolution and NCEs? To “prevent unwanted IPv6 packets from reaching the node”?


>  Yes, the benefit would be to prevent unwanted IPv6 packets from reaching the node.


And, provide security benefits of stable and private addresses?.


>  Whatever type of addresses the host configures, the router would use address resolution to

>  ensure that the host actually responds to the given address before sending any packets.

[[Dusan]] Question about “For delegated prefixes and individual prefixes that are not considered on-link”. If the “the router delivers all packets that match the prefix to the unicast link-layer address of the node”, doesn’t this violate the address privacy in RFC4941?


Can these benefits be added to ‘individual prefix’ definition?


>  I will add something.


Should these benefits go into the ‘unique ipv6 prefix per host’ draft?


>  There did not seem to be consensus to add anything to that draft.



-          7. IPv6 Neighbor Discovery Implications

“When a node receives a shared or individual prefix, it is required to
use the IPv6 ND address resolution function over the upstream
interface to determine the link-layer address of a neighbor”

The address resolution is done for ‘Send’ algorithm. Why is it needed for the prefix assignment?


>  That is correct – address resolution is part of the sending algorithm and not

>  part of prefix assignment. I will make sure to clarify that point.

Why is the address resolution required for the ‘individual’ prefix? Should not the node using the individual prefix send the packets to the first hop router (the on-link neighbor has a different ‘individual’ prefix and that prefix is not in the node’s prefix list)?


>  What I am meaning to say is that, if the node receives the individual prefix

>  2001:db8:1:2::/64 and configures the address 2001:db8:1:2::10, but then

>  tries to ping6 the non-existent address 2001:db8:1:2::20, it has to do

>  address resolution on the upstream interface which will fail. Do I have

>  that right, or did I make a mistake?

[[Dusan]] ping6 should go the first hope router on the upstream interface, without the address resolution. There is no another node assigned the same prefix. There is no need for the address resolution for 2001:db8:1:2::20.

“For delegated prefixes and individual prefixes that are not
considered on-link, the router delivers all packets that match the
prefix”
To where? Node’s link-layer unicast address?


>  The node’s IPv6 link-local address will be listed as the next hop in the

>  router’s forwarding table. So, address resolution for the link-local

>  address would reveal the node’s link-layer address and all packets

>  that match the prefix would be sent to the node’s link-layer address


Thanks a lot for your help,
Dusan.

From: Templin, Fred L [mailto:[e-mail]]
Sent: Wednesday, October 11, 2017 12:52 PM
To: Mudric, Dusan (Dusan); Lorenzo Colitti
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Dusan,

Thanks again for your useful comments - I updated ‘pdhost’ to resolve your questions
(see below). Please review and let me know if your points are addressed.

Thanks - Fred



-----Original Message-----
From: I-D-Announce [mailto:[e-mail]] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Wednesday, October 11, 2017 9:49 AM
To: [e-mail]<mailto:[e-mail]>
Subject: I-D Action: draft-templin-v6ops-pdhost-14.txt





A New Internet-Draft is available from the on-line Internet-Drafts directories.





        Title           : IPv6 Prefix Delegation for Hosts

        Author          : Fred L. Templin

                Filename        : draft-templin-v6ops-pdhost-14.txt

                Pages           : 12

                Date            : 2017-10-11



Abstract:

   IPv6 prefixes are typically delegated to requesting routers which

   then use them to number their downstream-attached links and networks.

   This document considers the case when the requesting router is a node

   that acts as a host on behalf of its local applications and as a

   router on behalf of any downstream networks.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dtemplin-2Dv6ops-2Dpdhost_&d=DwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=Eb5XUfV0A6sClwFnQpF5SxJ_Gak1PdPgbP9tLj33U9k&s=oQyz4ZL7nRjl4w-UOFD__FEq9BAVOErk4zKfvNKywB8&e=>



There are also htmlized versions available at:

https://tools.ietf.org/html/draft-templin-v6ops-pdhost-14<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dtemplin-2Dv6ops-2Dpdhost-2D14&d=DwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=Eb5XUfV0A6sClwFnQpF5SxJ_Gak1PdPgbP9tLj33U9k&s=t7h-qAzKyeNXj52Bd1ocM55trXAM-ULOYOm9iZ2zj-k&e=>

https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-14<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dtemplin-2Dv6ops-2Dpdhost-2D14&d=DwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=Eb5XUfV0A6sClwFnQpF5SxJ_Gak1PdPgbP9tLj33U9k&s=S0EAFQmdkX8K5N4Yw3j_zskqWcKgjxJRPdNwKKRZzX4&e=>



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-templin-v6ops-pdhost-14<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dtemplin-2Dv6ops-2Dpdhost-2D14&d=DwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=Eb5XUfV0A6sClwFnQpF5SxJ_Gak1PdPgbP9tLj33U9k&s=YGvZUUnvUW8TAoMb0lR163KBfGBXY_QXFnvkEmYOQV0&e=>





Please note that it may take a couple of minutes from the time of submission

until the htmlized version and diff are available at tools.ietf.org.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=Eb5XUfV0A6sClwFnQpF5SxJ_Gak1PdPgbP9tLj33U9k&s=t5HXG7Zhdj3axBFViESNpLbI0Hnc5WtFi3i1CpmpvOg&e=>



_______________________________________________

I-D-Announce mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/i-d-announce<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_i-2Dd-2Dannounce&d=DwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=Eb5XUfV0A6sClwFnQpF5SxJ_Gak1PdPgbP9tLj33U9k&s=HLsphMfYQJWMfLeqogtP5AjCpZMwq9aukzt2zk94jRc&e=>

Internet-Draft directories: http://www.ietf.org/shadow.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_shadow.html&d=DwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=Eb5XUfV0A6sClwFnQpF5SxJ_Gak1PdPgbP9tLj33U9k&s=0dssRxnxQaRH8ufnu48Y41lXLOs83K2I2LSPNIOTp3w&e=>

or ftp://ftp.ietf.org/ietf/1shadow-sites.txt<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_ietf_1shadow-2Dsites.txt&d=DwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=Eb5XUfV0A6sClwFnQpF5SxJ_Gak1PdPgbP9tLj33U9k&s=HAzlvpqBO4auAT3RoRaJyqI0mDMZS6nRNGQQi-eY0TY&e=>


From: v6ops [mailto:[e-mail]] On Behalf Of Templin, Fred L
Sent: Wednesday, October 11, 2017 8:46 AM
To: Mudric, Dusan (Dusan) <[e-mail]<mailto:[e-mail]>>; Lorenzo Colitti <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Mudric,

Thanks for the comments, and see below for responses. I will work new
text into the ‘pdhost’ draft and post a new version soon.

Fred

From: Mudric, Dusan (Dusan) [mailto:[e-mail]]
Sent: Wednesday, October 11, 2017 8:34 AM
To: Templin, Fred L <[e-mail]<mailto:[e-mail]>>; Lorenzo Colitti <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Fred,


Good point. Can you please provide some text explaining the security advantages of 2) and 3) over 1)?



>   Yes, I can work on this and add something to the draft.



'draft-templin-v6ops-pdhost' defines "shared", "individual", and "delegated" prefixes, where "individual” prefixes are introduced by ietf-v6ops-unique-ipv6-prefix-per-host. This draft should clearly state when and why some “individual” prefix algorithms are, and are NOT, run (i.e. DAD, neighbor discovery, …). This will clarify the impact of this draft on hosts.



>   The draft currently talks about DAD and ND considerations for item 3), but can be

>   extended to compare with DAD/ND considerations for the other options.



Thanks,

Dusan.


From: Templin, Fred L [mailto:[e-mail]]
Sent: Friday, October 06, 2017 11:08 AM
To: Mudric, Dusan (Dusan); Lorenzo Colitti
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Dusan,

To my understanding, we have 1) shared prefixes, 2) individual (“unique”) prefixes and 3) delegated prefixes.
‘ietf-v6ops-unique-ipv6-prefx-per-host’ talks about 1) and 2), while ‘templin-v6ops-pdhost’ talks about 3).

Do you want to also consider delegated prefixes?

Thanks - Fred

From: Mudric, Dusan (Dusan) [mailto:[e-mail]]
Sent: Friday, October 06, 2017 7:48 AM
To: Lorenzo Colitti <[e-mail]<mailto:[e-mail]>>; Templin, Fred L <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Fred,

Should it be mentioned that even though a ‘shared’ prefix with L=0 makes hosts send packets over the first hope router, the unique prefix per host is preferred mechanism in the environments where security is of a concern?

Thanks,
Dusan.

From: v6ops [mailto:[e-mail]] On Behalf Of Lorenzo Colitti
Sent: Wednesday, September 13, 2017 6:04 PM
To: Templin, Fred L
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

I would instead say the opposite, i.e., call attention to what is in fact one of the the main benefits of this document. Suggested text:

The practices described in this document make it very simple for networks to implement robust isolation between clients at layer 2. The network can simply ensure that devices cannot send packets to each other except through the first-hop router. This will automatically provide robust protection against attacks between devices that rely on link-local ICMPv6 packets, such as DAD reply spoofing, ND cache exhaustion, malicious redirects, and rogue RAs. This form of protection is much more scalable and robust than alternative mechanisms such as DAD proxying, forced forwarding, or ND snooping.



On Wed, Sep 13, 2017 at 2:12 PM, Templin, Fred L <[e-mail]<mailto:[e-mail]>> wrote:
Please add the following to Security Considerations:

  "While the practices described herein encourage L3 operations that would
    forward all traffic through a provider managed First Hop Router, peer to peer
    communications are still possible unless L2 mechanisms are also employed
    in some fashion outside the scope of this document."

Thanks - Fred

> -----Original Message-----
> From: v6ops [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of [e-mail]<mailto:[e-mail]>
> Sent: Wednesday, September 13, 2017 7:04 AM
> To: [e-mail]<mailto:[e-mail]>
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the IPv6 Operations WG of the IETF.
>
>         Title           : Unique IPv6 Prefix Per Host
>         Authors         : John Jason Brzozowski
>                           Gunter Van De Velde
>       Filename        : draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt
>       Pages           : 9
>       Date            : 2017-09-13
>
> Abstract:
>    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 service provider IPv6 address include
>    improved host isolation and enhanced subscriber management on shared
>    network segments.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dv6ops-2Dunique-2Dipv6-2Dprefix-2Dper-2Dhost_&d=DwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=PlXnFjk4NtNYXkaHFxRI86HSymtz8QLmdZMdwJQhLUY&s=Z0NT1ldV3az-PlcrolYWmpzjzXI-e9gIFUUG7GqakVA&e=>
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-08<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dv6ops-2Dunique-2Dipv6-2Dprefix-2Dper-2Dhost-2D08&d=DwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=PlXnFjk4NtNYXkaHFxRI86HSymtz8QLmdZMdwJQhLUY&s=iwcdOKuejV0qgA7XtQEwy-NPAasakqiys1hP46IrLVs&e=>
> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-08<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dv6ops-2Dunique-2Dipv6-2Dprefix-2Dper-2Dhost-2D08&d=DwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=PlXnFjk4NtNYXkaHFxRI86HSymtz8QLmdZMdwJQhLUY&s=JGWGoSnzdqBvDMseLJY0jyuaFE1nd-c6bZD9ehddnQo&e=>
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-08<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dv6ops-2Dunique-2Dipv6-2Dprefix-2Dper-2Dhost-2D08&d=DwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=PlXnFjk4NtNYXkaHFxRI86HSymtz8QLmdZMdwJQhLUY&s=KKbJOoGAffY7kkEZ1sT7fHIl09DX2kdlChL3_Ox38mY&e=>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=PlXnFjk4NtNYXkaHFxRI86HSymtz8QLmdZMdwJQhLUY&s=7APWKVKyyoeqrSUx4M-UUhMlzxXL3hkgcCmZSRUxoPI&e=>.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=PlXnFjk4NtNYXkaHFxRI86HSymtz8QLmdZMdwJQhLUY&s=AxI18cu2PadGwT3HHZOGQbNC7idjhV_I_q466Ssm15E&e=>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/v6ops<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_v6ops&d=DwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=PlXnFjk4NtNYXkaHFxRI86HSymtz8QLmdZMdwJQhLUY&s=gfIYhPTUIDst9iCDPwjpqx-FJKKNJ9ney-huyDVfwy4&e=>


_______________________________________________
v6ops mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/v6ops<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_v6ops&d=DwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=PlXnFjk4NtNYXkaHFxRI86HSymtz8QLmdZMdwJQhLUY&s=gfIYhPTUIDst9iCDPwjpqx-FJKKNJ9ney-huyDVfwy4&e=>