Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Fri, 6 Oct 2017 14:48:09 +0000

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:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Wednesday, September 13, 2017 6:04 PM
To: Templin, Fred L
Cc: [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
> Sent: Wednesday, September 13, 2017 7:04 AM
> To: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>
> 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
> [email-masked]<mailto:[email-masked]>
> 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
[email-masked]<mailto:[email-masked]>
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=>

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 6 Oct 2017 15:07:45 +0000

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:[email-masked]]
Sent: Friday, October 06, 2017 7:48 AM
To: Lorenzo Colitti <[email-masked]>; Templin, Fred L <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Fred,

Thanks,
Dusan.

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

Thanks - Fred

---

From: Fred Baker <[email-masked]>
Date: Mon, 9 Oct 2017 06:16:45 -0700

Unless someone wants to tell me I'm wrong, I don't think that consensus exists. What the document says is that when someone is running a service such as described, traffic from the CPE router to which a prefix has been delegated should invariably travel through the upstream router as opposed to directly to a router that might appear to be an immediate neighbor. It doesn't deprecate the use of SLAAC/DHCPv6 or the use of neighbor-to-neighbor routing in LAN networks.

> On Oct 6, 2017, at 7:48 AM, Mudric, Dusan (Dusan) <[email-masked]> wrote:
> 
> Hi Fred,
> 
> On Wed, Sep 13, 2017 at 2:12 PM, Templin, Fred L <[email-masked]> wrote:
> > From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]
> > To: [email-masked]
> > Cc: [email-masked]
> > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/
> >
> > https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-08
> > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-08
> >
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-08
> >
> >
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 9 Oct 2017 14:34:11 +0000

Fred,

> From: Fred Baker [mailto:[email-masked]]
> Sent: Monday, October 09, 2017 6:17 AM
> To: Mudric, Dusan (Dusan) <[email-masked]>
> Cc: Lorenzo Colitti <[email-masked]>; Templin, Fred L <[email-masked]>; [email-masked]; [email-masked]
> Unless someone wants to tell me I'm wrong, I don't think that consensus exists. What the document says is that when someone is
> running a service such as described, traffic from the CPE router to which a prefix has been delegated should invariably travel through

'draft-ietf-v6ops-unique-ipv6-prefix-per-host' is not about prefix delegation.
'draft-templin-v6ops-pdhost' is about prefix delegation.

Thanks - Fred

> the upstream router as opposed to directly to a router that might appear to be an immediate neighbor. It doesn't deprecate the use
> of SLAAC/DHCPv6 or the use of neighbor-to-neighbor routing in LAN networks.
> 
> > 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.
> >
> > 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.
> >
> >
> >

---

From: Fred Baker <[email-masked]>
Date: Mon, 9 Oct 2017 16:30:50 -0700

> On Oct 9, 2017, at 7:34 AM, Templin, Fred L <[email-masked]> wrote:
> 
> Fred,
> 

No, it's about a service (presumably operated by an ISP) in which prefixes are delegated to hosts. While the specification is clear that the ISP might *also* IPv4 service on the same network using the same equipment, what is specified is an IPv6, and potentially IPv6-only, service.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 10 Oct 2017 14:39:07 +0000

Fred,

> Sent: Monday, October 09, 2017 4:31 PM
> To: Templin, Fred L <[email-masked]>
> Cc: Mudric, Dusan (Dusan) <[email-masked]>; Lorenzo Colitti <[email-masked]>; [email-masked]; [email-masked]
> No, it's about a service (presumably operated by an ISP) in which prefixes are delegated to hosts.

It is not a prefix delegation service. It is a service that advertises a unique prefix to
a host, where the host is unaware that the prefix is unique and the host does not
participate in explicit prefix delegation procedures in any way. The host therefore
has no way of knowing whether the prefix is on-link on the upstream interface,
and therefore has to do DAD when it assigns an address to the upstream interface.

Prefix delegation is when the host is aware that the prefix is being delegated for
its own exclusive use and can therefore assign the prefix to downstream networks
and perform unlimited multi-addressing without having to invoke DAD on the
upstream interface.

Please read the definitions for "shared", "individual", and "delegated" prefixes
in 'draft-templin-v6ops-pdhost'.

Thanks - Fred

> While the specification is clear that
> the ISP might *also* IPv4 service on the same network using the same equipment, what is specified is an IPv6, and potentially IPv6-
> only, service.
>

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Wed, 11 Oct 2017 15:33:57 +0000

Hi Fred,

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

'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.

Thanks,

Dusan.

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

Hi Dusan,

Thanks - Fred

Hi Fred,

Thanks,
Dusan.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 11 Oct 2017 15:46:17 +0000

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:[email-masked]]
Sent: Wednesday, October 11, 2017 8:34 AM
To: Templin, Fred L <[email-masked]>; Lorenzo Colitti <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Fred,

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

Ø    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.

Hi Dusan,

Thanks - Fred

To: Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>; Templin, Fred L <[email-masked]<mailto:[email-masked]>>

Hi Fred,

Thanks,
Dusan.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 11 Oct 2017 16:52:18 +0000

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:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, October 11, 2017 9:49 AM
To: [email-masked]
Subject: I-D Action: draft-templin-v6ops-pdhost-14.txt

        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.

https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/

https://tools.ietf.org/html/draft-templin-v6ops-pdhost-14

https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-14

https://www.ietf.org/rfcdiff?url2=draft-templin-v6ops-pdhost-14

I-D-Announce mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/i-d-announce

Internet-Draft directories: http://www.ietf.org/shadow.html

or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Hi Mudric,

Fred

To: Templin, Fred L <[email-masked]<mailto:[email-masked]>>; Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>

Hi Fred,

Thanks,

Dusan.

Hi Dusan,

Thanks - Fred

Hi Fred,

Thanks,
Dusan.

Thanks - Fred

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Wed, 11 Oct 2017 18:36:53 +0000

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?

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),

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

§  and rogue RAs?

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

-          ‘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”? And, provide security benefits of stable and private addresses?. Can these benefits be added to ‘individual prefix’ definition? Should these benefits go into the ‘unique ipv6 prefix per host’ 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?

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)?

“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?

Thanks a lot for your help,
Dusan.

Sent: Wednesday, October 11, 2017 12:52 PM

Hi Dusan,

Thanks - Fred

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

        Author          : Fred L. Templin

                Pages           : 12

                Date            : 2017-10-11

Abstract:

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=>

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=>

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=>

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=>

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=>

To: Mudric, Dusan (Dusan) <[email-masked]<mailto:[email-masked]>>; Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>

Hi Mudric,

Fred

Hi Fred,

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

>   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.

Hi Dusan,

Thanks - Fred

Hi Fred,

Thanks,
Dusan.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 11 Oct 2017 21:35:13 +0000

Hi Dusan,

Responses below:

Thanks - Fred

Sent: Wednesday, October 11, 2017 11:37 AM

Hi Fred,

-          General questions:

Ø  I cannot speak for that document.

Ø  Certainly yes about these items.

§  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?

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

-          ‘individual prefix’

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.

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.

Ø  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.

Ø  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?

Ø  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

Hi Dusan,

Thanks - Fred

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

        Author          : Fred L. Templin

                Pages           : 12

                Date            : 2017-10-11

Abstract:

Hi Mudric,

Fred

Hi Fred,

Thanks,

Dusan.

Hi Dusan,

Thanks - Fred

Hi Fred,

Thanks,
Dusan.

Thanks - Fred

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 14 Oct 2017 14:22:30 +0900

In reality I suspect that that is, in fact, the current IETF best practice.
That the ways I see to implement that sort of security are to 1) have
different hosts share one prefix, but keep track of which IP addresses
belong to which hosts or 2) have different hosts on different prefixes. In
the presence of hostile actors, #1 is very expensive to build while meeting
the recommendations in RFC 7934.

On Mon, Oct 9, 2017 at 10:16 PM, Fred Baker <[email-masked]>
wrote:

> Unless someone wants to tell me I'm wrong, I don't think that consensus
> exists. What the document says is that when someone is running a service
> such as described, traffic from the CPE router to which a prefix has been
> delegated should invariably travel through the upstream router as opposed
> to directly to a router that might appear to be an immediate neighbor. It
> doesn't deprecate the use of SLAAC/DHCPv6 or the use of
> neighbor-to-neighbor routing in LAN networks.
>
> > 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.
> >
> > 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.
> >
> >
> >

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 17 Oct 2017 14:28:22 +0000

Hi Dusan,

I created a -15 version of ‘draft-templin-v6ops-pdhost’ to resolve your points.
Please have a look and let me know if you have any further comments:

Thanks - Fred

Hi Fred,

-          General questions:

§  and rogue RAs?

-          ‘individual prefix’

Hi Dusan,

Thanks - Fred

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

        Author          : Fred L. Templin

                Pages           : 12

                Date            : 2017-10-11

Abstract:

Hi Mudric,

Fred

Hi Fred,

Thanks,

Dusan.

Hi Dusan,

Thanks - Fred

Hi Fred,

Thanks,
Dusan.

Thanks - Fred

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Tue, 17 Oct 2017 18:39:06 +0000

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 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.

Sent: Wednesday, October 11, 2017 5:35 PM

Hi Dusan,

Responses below:

Thanks - Fred

Hi Fred,

-          General questions:

>  I cannot speak for that document.

•  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?

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

-          ‘individual prefix’

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

>  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?

>  I will add something.

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

>  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.

>  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.

>  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

Hi Dusan,

Thanks - Fred

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

        Author          : Fred L. Templin

                Pages           : 12

                Date            : 2017-10-11

Abstract:

Hi Mudric,

Fred

Hi Fred,

Thanks,

Dusan.

Hi Dusan,

Thanks - Fred

Hi Fred,

Thanks,
Dusan.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 17 Oct 2017 19:36:13 +0000

Hi Dusan,

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.

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.

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.

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.

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.

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?

Thanks - Fred

Sent: Tuesday, October 17, 2017 11:39 AM

Hi Fred,

Thanks for the updates.

Thanks,
Dusan.

Hi Dusan,

Responses below:

Thanks - Fred

Hi Fred,

-          General questions:

•  and rogue RAs?

-          ‘individual prefix’

Hi Dusan,

Thanks - Fred

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

        Author          : Fred L. Templin

                Pages           : 12

                Date            : 2017-10-11

Abstract:

Hi Mudric,

Fred

Hi Fred,

Thanks,

Dusan.

Hi Dusan,

Thanks - Fred

Hi Fred,

Thanks,
Dusan.

Thanks - Fred

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Tue, 17 Oct 2017 20:49:49 +0000

Hi Fred,

Please see inlined

Thanks,
Dusan.

Sent: Tuesday, October 17, 2017 3:36 PM

Hi Dusan,

[[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?

[[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]] 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.

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

Hi Fred,

Thanks for the updates.

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?

Thanks,
Dusan.

Hi Dusan,

Responses below:

Thanks - Fred

Hi Fred,

-          General questions:

•  and rogue RAs?

-          ‘individual prefix’

Hi Dusan,

Thanks - Fred

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

        Author          : Fred L. Templin

                Pages           : 12

                Date            : 2017-10-11

Abstract:

Hi Mudric,

Fred

Hi Fred,

Thanks,

Dusan.

Hi Dusan,

Thanks - Fred

Hi Fred,

Thanks,
Dusan.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 17 Oct 2017 21:53:57 +0000

Hi Dusan,

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, …”

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.

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

Sent: Tuesday, October 17, 2017 1:50 PM

Hi Fred,

Please see inlined

Thanks,
Dusan.

Hi Dusan,

Thanks - Fred

Hi Fred,

Thanks for the updates.

Thanks,
Dusan.

Hi Dusan,

Responses below:

Thanks - Fred

Hi Fred,

-          General questions:

•  and rogue RAs?

-          ‘individual prefix’

Hi Dusan,

Thanks - Fred

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

        Author          : Fred L. Templin

                Pages           : 12

                Date            : 2017-10-11

Abstract:

Hi Mudric,

Fred

Hi Fred,

Thanks,

Dusan.

Hi Dusan,

Thanks - Fred

Hi Fred,

Thanks,
Dusan.

Thanks - Fred

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Wed, 18 Oct 2017 16:46:20 +0000

Hi Fred,

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

Regards,
Dusan.

Sent: Tuesday, October 17, 2017 5:54 PM

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 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.

Thanks - Fred

Hi Fred,

Please see inlined

Thanks,
Dusan.

Hi Dusan,

Thanks - Fred

Hi Fred,

Thanks for the updates.

Thanks,
Dusan.

Hi Dusan,

Responses below:

Thanks - Fred

Hi Fred,

-          General questions:

•  and rogue RAs?

-          ‘individual prefix’

Hi Dusan,

Thanks - Fred

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

        Author          : Fred L. Templin

                Pages           : 12

                Date            : 2017-10-11

Abstract:

Hi Mudric,

Fred

Hi Fred,

Thanks,

Dusan.

Hi Dusan,

Thanks - Fred

Hi Fred,

Thanks,
Dusan.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 18 Oct 2017 20:32:11 +0000

Hi Dusan,

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. 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.

Thanks - Fred

Sent: Wednesday, October 18, 2017 9:46 AM

Hi Fred,

Regards,
Dusan.

Hi Dusan,

Thanks - Fred

Hi Fred,

Please see inlined

Thanks,
Dusan.

Hi Dusan,

Thanks - Fred

Hi Fred,

Thanks for the updates.

Thanks,
Dusan.

Hi Dusan,

Responses below:

Thanks - Fred

Hi Fred,

-          General questions:

•  and rogue RAs?

-          ‘individual prefix’

Hi Dusan,

Thanks - Fred

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

        Author          : Fred L. Templin

                Pages           : 12

                Date            : 2017-10-11

Abstract:

Hi Mudric,

Fred

Hi Fred,

Thanks,

Dusan.

Hi Dusan,

Thanks - Fred

Hi Fred,

Thanks,
Dusan.

Thanks - Fred

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Fri, 20 Oct 2017 14:28:19 +0000

Hi Fred,

Please find inlined.

Thanks,
Dusan.

Sent: Wednesday, October 18, 2017 4:32 PM

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’.

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

Hi Fred,

Regards,
Dusan.

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.

Thanks - Fred

Hi Fred,

Please see inlined

Thanks,
Dusan.

Hi Dusan,

Thanks - Fred

Hi Fred,

Thanks for the updates.

Thanks,
Dusan.

Hi Dusan,

Responses below:

Thanks - Fred

Hi Fred,

-          General questions:

•  and rogue RAs?

-          ‘individual prefix’

Hi Dusan,

Thanks - Fred

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

        Author          : Fred L. Templin

                Pages           : 12

                Date            : 2017-10-11

Abstract:

Hi Mudric,

Fred

Hi Fred,

Thanks,

Dusan.

Hi Dusan,

Thanks - Fred

Hi Fred,

Thanks,
Dusan.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 20 Oct 2017 15:02:18 +0000

Hi Dusan,

Responding to your comments:

Certainly. But, note that that document is now expired.
[[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’.
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

Sent: Friday, October 20, 2017 7:28 AM

Hi Fred,

Please find inlined.

Thanks,
Dusan.

Hi Dusan,

Thanks - Fred

Hi Fred,

Regards,
Dusan.

Hi Dusan,

Thanks - Fred

Hi Fred,

Please see inlined

Thanks,
Dusan.

Hi Dusan,

Thanks - Fred

Hi Fred,

Thanks for the updates.

Thanks,
Dusan.

Hi Dusan,

Responses below:

Thanks - Fred

Hi Fred,

-          General questions:

•  and rogue RAs?

-          ‘individual prefix’

Hi Dusan,

Thanks - Fred

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

        Author          : Fred L. Templin

                Pages           : 12

                Date            : 2017-10-11

Abstract:

Hi Mudric,

Fred

Hi Fred,

Thanks,

Dusan.

Hi Dusan,

Thanks - Fred

Hi Fred,

Thanks,
Dusan.

Thanks - Fred