Subject: Re: [v6ops] IPv6 Prefix Delegation Models ('draft-templin-v6ops-pdhost') - draft update

From: Erik Nygren <[email-masked]>
Date: Fri, 15 Jun 2018 17:23:46 -0400

I think this is extremely useful work.  Some additional thoughts:

* Container systems (eg, Docker) are an important illustrative use-case
here worth mentioning in addition to VMs.
  For example, see the Docker IPv6 implementation notes describe something
very similar to
  what we are describing here:
     https://docs.docker.com/v17.09/engine/userguide/
networking/default_network/ipv6/
  It assumes each Docker server has its own prefix (eg, at least /80 but
many of the examples are /64)
  that it assigns to containers out of.  They give two examples, one for ND
proxying
  and one for next-hop routing.  The lack of PD-host model support in cloud
service providers
  such as AWS makes it much harder to deploy IPv6 and Docker on something
like AWS
  without resorting to horrible NAT66 hacks.

* Another good illustrative use-case example might be implementing a NAT64
or similar service.

* Perhaps talk more (in the introduction, if not elsewhere?) about what
addresses get
  used for the next-hop when F is talking to R, in-terms of when it is
using a link-local
  vs global-unicast address on R.  There are likely use-cases for both?

* Section 8 could use some better examples as well as some clarifications
for readability.
  For example, when saying "When a node receives a shared or individual
prefix"
  it should say over what protocol or type of message.
  And for "The node further does not perform the
 IPv6 ND address resolution function over upstream interfaces"
 this should be clarified as for just being for addresses within the
delegated prefix.
 It would also help to clarify which cases the delegated prefixes
 being discussed are for that node or for a node it wishes to talk to.
  (ie, clarify the behavior for a node that shares an upstream
interface/link
  with one or more hosts that have delegated prefixes.)

* For security considerations, some attacks may still be possible through
  on-net hosts.  (eg, if the local network contains an open recursive DNS
resolver
  it could be tricked into making lots of on-upstream ND requests for the
prefix.)
  This may fall into existing ND considerations, but is a corner case where
  the prefix delegation may not help enough?

* Static provisioning plus iBGP next-hop advertisements is another
  provisioning mechanism that I've seen used.   (For example, to assign 256
/64 delegated prefixes
  out of a single statically assigned /56 to route to ND-managed
global-unicast service addresses.
  This has worked well other than being a pain to convince networks that it
is reasonable to support.)

* Is it work mentioning use-cases for "shared delegated prefixes",
  or does that add confusion and should be a topic for a future draft?
  In particular where nodes share a delegated prefix and the first-hop
router F
  load-balances between them, such as via ECMP.  A use-case might be a
NAT64
  or lw4o6 decapsulation service where one prefix is effectively delegated
to a set
  of hosts which each have intentionally duplicate addresses.
  The primary change ends up being with ND.

Best, Erik

On Tue, May 29, 2018 at 3:13 PM, Templin (US), Fred L <
[email-masked]> wrote:

> See below for a draft update to "IPv6 Prefix Delegation Models
> ('draft-templin-v6ops-pdhost').
> This version (-20) updates figure 1 and adds informative text on the
> relation to multi-addressing
> (RFC7934 and RFC8273). Please review and comment.
>
> Fred
>
> -----Original Message-----
> From: I-D-Announce [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, May 29, 2018 12:02 PM
> To: [email-masked]
> Subject: I-D Action: draft-templin-v6ops-pdhost-20.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>         Title           : IPv6 Prefix Delegation Models
>         Author          : Fred L. Templin
>         Filename        : draft-templin-v6ops-pdhost-20.txt
>         Pages           : 14
>         Date            : 2018-05-29
>
> Abstract:
>    IPv6 prefixes are typically delegated to requesting routers which
>    assign them to their downstream-attached links and networks.  The
>    requesting node can provision the prefix according to whether it acts
>    as a router on behalf of any downstream networks and/or as a host on
>    behalf of its local applications.  In the latter case, the requesting
>    node can use portions of the delegated prefix for its own multi-
>    addressing purposes.  This document therefore considers prefix
>    delegation models for both the classic routing and multi-addressing
>    use cases.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-templin-v6ops-pdhost-20
> https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-20
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-templin-v6ops-pdhost-20
>
>
> 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/
>
> _______________________________________________
> I-D-Announce mailing list
> [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
>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 18 Jun 2018 19:11:13 +0000

Hi Erik,

Thanks very much for these comments. See below for responses:

From: [email-masked] [mailto:[email-masked]] On Behalf Of Erik Nygren
Sent: Friday, June 15, 2018 2:24 PM
To: Templin (US), Fred L <[email-masked]>
Cc: v6ops list <[email-masked]>
Subject: Re: [v6ops] IPv6 Prefix Delegation Models ('draft-templin-v6ops-pdhost') - draft update

* Container systems (eg, Docker) are an important illustrative use-case here worth mentioning in addition to VMs.
  For example, see the Docker IPv6 implementation notes describe something very similar to
  what we are describing here:
     https://docs.docker.com/v17.09/engine/userguide/networking/default_network/ipv6/
  It assumes each Docker server has its own prefix (eg, at least /80 but many of the examples are /64)
  that it assigns to containers out of.  They give two examples, one for ND proxying
  and one for next-hop routing.  The lack of PD-host model support in cloud service providers
  such as AWS makes it much harder to deploy IPv6 and Docker on something like AWS
  without resorting to horrible NAT66 hacks.

>> Yes, I think it would be good to mention Container systems such as Docker that could

>> be expected to occur in downstream internal virtual networks serviced in the classic

>> routing model. I think it would be good to also say that this sort of prefix delegation

>> avoids the need for NAT66 in downstream networks – that is an important aspect

>> of the models.

* Another good illustrative use-case example might be implementing a NAT64 or similar service.

>> Not sure how you mean by implementing NAT64 – the scope of this document is IPv6
>> only. Do you see a reason NAT64 should come into this document?

* Perhaps talk more (in the introduction, if not elsewhere?) about what addresses get
  used for the next-hop when F is talking to R, in-terms of when it is using a link-local
  vs global-unicast address on R.  There are likely use-cases for both?

>> F and R are assumed to be on the same link, but I can make this more clear in the
>> document. Because they are on the same link, IPv6 link-local addressing on the
>> link can be assumed for F at least and probably also for R. It is true that R could
>> autoconfigure a global address for itself on the F<->R link. But, Prefix Delegation
>> maintenance exchanges would be based on the same link-local addresses used
>> to procure the initial Prefix Delegation.

* Section 8 could use some better examples as well as some clarifications for readability.
  For example, when saying "When a node receives a shared or individual prefix"
  it should say over what protocol or type of message.

>> Perhaps say: “e.g., via a PIO included in an RA message” ?

  And for "The node further does not perform the
 IPv6 ND address resolution function over upstream interfaces"
 this should be clarified as for just being for addresses within the delegated prefix.

>> Correct - will fix.

 It would also help to clarify which cases the delegated prefixes
 being discussed are for that node or for a node it wishes to talk to.
  (ie, clarify the behavior for a node that shares an upstream interface/link
  with one or more hosts that have delegated prefixes.)

>> This is indeed an important consideration to emphasize, and would benefit from
>> an additional sentence at the beginning of the third paragraph in that Section.
>> How does this sound:
>>
>>   “Many requesting nodes that receive Prefix Delegations may be connected
>>     to the same (shared) upstream link, but may not be running a dynamic
>>     routing protocol over that link.”

* For security considerations, some attacks may still be possible through
  on-net hosts.  (eg, if the local network contains an open recursive DNS resolver
  it could be tricked into making lots of on-upstream ND requests for the prefix.)
  This may fall into existing ND considerations, but is a corner case where
  the prefix delegation may not help enough?

>> I am open to any text suggestions you may have for this.

* Static provisioning plus iBGP next-hop advertisements is another
  provisioning mechanism that I've seen used.   (For example, to assign 256 /64 delegated prefixes
  out of a single statically assigned /56 to route to ND-managed global-unicast service addresses.
  This has worked well other than being a pain to convince networks that it is reasonable to support.)

>> Yes, this belongs as an example in Section 10.

* Is it work mentioning use-cases for "shared delegated prefixes",
  or does that add confusion and should be a topic for a future draft?
  In particular where nodes share a delegated prefix and the first-hop router F
  load-balances between them, such as via ECMP.  A use-case might be a NAT64
  or lw4o6 decapsulation service where one prefix is effectively delegated to a set
  of hosts which each have intentionally duplicate addresses.
  The primary change ends up being with ND.

>> Very interesting point, but I think beyond the scope of what we are doing here.
>> The nominal example this document intends to honor is RFC3633-style PD (or
>> any other comparable service) where a prefix is delegated to one and only one
>> requesting node. Perhaps this could go into a separate document, and/or we
>> could add a few words here to describe the use case but declare it out of scope?

Thanks - Fred

Best, Erik

On Tue, May 29, 2018 at 3:13 PM, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:
See below for a draft update to "IPv6 Prefix Delegation Models ('draft-templin-v6ops-pdhost').
This version (-20) updates figure 1 and adds informative text on the relation to multi-addressing
(RFC7934 and RFC8273). Please review and comment.

Fred

-----Original Message-----
From: I-D-Announce [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, May 29, 2018 12:02 PM
To: [email-masked]<mailto:[email-masked]>
Subject: I-D Action: draft-templin-v6ops-pdhost-20.txt

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

Abstract:

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<http://tools.ietf.org>.

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

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops