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

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 29 May 2018 19:13:58 +0000

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

---

From: Fred Baker <[email-masked]>
Date: Wed, 30 May 2018 03:14:42 +0200

General question to those who commented on the draft when we discussed it a few weeks ago: do you agree that this update addresses the issues you raised? Do you have further comments on it?

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 30 May 2018 15:41:06 +0200

I propose this figure as well, in which an IoT router 'R' does not form 
any address A on any of its interfaces, out of the delegated prefix P,
even though it _does_ request and obtain a prefix P and does RA it to 
other nodes in the network in controls.

                                    x
                                    |
                      upstream link |
                                    |
                         +----------+----------+
                         |  upstream interface |
                         +--+-+--+-+--+-----+--+
                         |                     |
                         | requesting node 'R' |
                         |                     |
                         +---------------------+

For comparison, the figures present now in -20 are these:

                                    x
                                    |
                      upstream link |
                                    |
                         +----------+----------+
                         |  upstream Interface |
                         +---------------------+
                         |                     |
                         | requesting node 'R' |
                         |                     |
                         +--+-+--+-+--+-----+--+
                         |A1| |A2| |A3| ... |An|
                         +--+-+--+-+--+-----+--+
                         |  virtual Interface  |
                         +---------------------+

                       Figure 2: Weak End System Model

                                    x
                                    |
                      upstream link |
                                    |
                         +----------+----------+
                         |  upstream interface |
                         +--+-+--+-+--+-----+--+
                         |A1| |A2| |A3| ... |An|
                         +--+-+--+-+--+-----+--+
                         |                     |
                         | requesting node 'R' |
                         |                     |
                         +---------------------+
                         |   virtual interface |
                         +---------------------+
                       Figure 3: Strong End System Model

Le 30/05/2018 à 03:14, Fred Baker a écrit :
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 30 May 2018 15:43:48 +0000

Hi Alex,

Good point, but I think the new figure you are proposing is already covered under
figure 1. Figure 1 is an IoT router that does RA to other nodes in the networks it
controls – whether the networks are internal virtual networks or external
physical networks. Perhaps some extra text to explain the IoT and downsteam
network RA use case in conjunction with Figure 1 would help? Any suggestions?

Thanks - Fred

From: v6ops [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Wednesday, May 30, 2018 6:41 AM
To: [email-masked]
Subject: Re: [v6ops] IPv6 Prefix Delegation Models ('draft-templin-v6ops-pdhost') - draft update

I propose this figure as well, in which an IoT router 'R' does not form any address A on any of its interfaces, out of the delegated prefix P,
even though it _does_ request and obtain a prefix P and does RA it to other nodes in the network in controls.

                                   x

                                   |

                     upstream link |

                                   |

                        +----------+----------+

                        |  upstream interface |

                        +--+-+--+-+--+-----+--+

                        |                     |

                        | requesting node 'R' |

                        |                     |

                        +---------------------+

                                   x

                                   |

                     upstream link |

                                   |

                        +----------+----------+

                        |  upstream Interface |

                        +---------------------+

                        |                     |

                        | requesting node 'R' |

                        |                     |

                        +--+-+--+-+--+-----+--+

                        |A1| |A2| |A3| ... |An|

                        +--+-+--+-+--+-----+--+

                        |  virtual Interface  |

                        +---------------------+

                                   x

                                   |

                     upstream link |

                                   |

                        +----------+----------+

                        |  upstream interface |

                        +--+-+--+-+--+-----+--+

                        |A1| |A2| |A3| ... |An|

                        +--+-+--+-+--+-----+--+

                        |                     |

                        | requesting node 'R' |

                        |                     |

                        +---------------------+

                        |   virtual interface |

                        +---------------------+

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

v6ops mailing list

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 31 May 2018 11:34:02 +0200

Hi Fred,

But Figure 1 has Addresses allocated on the downstream interfaces, 
whereas I am talking about not put any Address on them be they virtual 
or real.

Alex

Le 30/05/2018 à 17:43, Templin (US), Fred L a écrit :
> *From:*v6ops [mailto:[email-masked]] *On Behalf Of *Alexandre 
> Petrescu
> *Sent:* Wednesday, May 30, 2018 6:41 AM
> *To:* [email-masked]
> *Subject:* Re: [v6ops] IPv6 Prefix Delegation Models 
> ('draft-templin-v6ops-pdhost') - draft update
>
> I propose this figure as well, in which an IoT router 'R' does not 
> form any address A on any of its interfaces, out of the delegated 
> prefix P,
>     On May 29, 2018, at 9:13 PM, Templin (US), Fred L<[email-masked]> <mailto:[email-masked]>  wrote:
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 31 May 2018 15:04:46 +0000

Alex,

I don’t quite follow – do you want us to document the case where the
requesting node receives a delegated prefix and then does nothing
with it at all?

The node needs at least one globally-unique address assigned to some
interface so that it can source ICMP messages that need to travel more
than one hop. It is true that that address could come from SLAAC using
an RA PIO instead of from the delegated prefix. But is the case of not
doing anything at all with the delegated prefix interesting?

Thanks - Fred

From: Alexandre Petrescu [mailto:[email-masked]]
Sent: Thursday, May 31, 2018 2:34 AM
To: Templin (US), Fred L <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] IPv6 Prefix Delegation Models ('draft-templin-v6ops-pdhost') - draft update

Hi Fred,

But Figure 1 has Addresses allocated on the downstream interfaces, whereas I am talking about not put any Address on them be they virtual or real.

Alex

Thanks - Fred

From: v6ops [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Wednesday, May 30, 2018 6:41 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] IPv6 Prefix Delegation Models ('draft-templin-v6ops-pdhost') - draft update

                                   x

                                   |

                     upstream link |

                                   |

                        +----------+----------+

                        |  upstream interface |

                        +--+-+--+-+--+-----+--+

                        |                     |

                        | requesting node 'R' |

                        |                     |

                        +---------------------+

                                   x

                                   |

                     upstream link |

                                   |

                        +----------+----------+

                        |  upstream Interface |

                        +---------------------+

                        |                     |

                        | requesting node 'R' |

                        |                     |

                        +--+-+--+-+--+-----+--+

                        |A1| |A2| |A3| ... |An|

                        +--+-+--+-+--+-----+--+

                        |  virtual Interface  |

                        +---------------------+

                                   x

                                   |

                     upstream link |

                                   |

                        +----------+----------+

                        |  upstream interface |

                        +--+-+--+-+--+-----+--+

                        |A1| |A2| |A3| ... |An|

                        +--+-+--+-+--+-----+--+

                        |                     |

                        | requesting node 'R' |

                        |                     |

                        +---------------------+

                        |   virtual interface |

                        +---------------------+

v6ops mailing list

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 31 May 2018 17:36:22 +0200

> requesting node receives a delegated prefix and then does nothing

No, I do not want to express such a case.

In this particular little case the node reveives a delegated prefix 
_and_ advertises it in RA further down.  YEt it does not use it to form 
any address for itself.
In order to form an address for itself the node uses the prefix received 
in the RA from the cellular network (not from DHCP PD).

> an RA PIO instead of from the delegated prefix.
>

I agree.

> But is the case of not

It is not "not doing anything at all with the delegated prefix".  It 
does several things with the delegated prefix:
- derives sub-prefixes out of it, making seveal /64s out of a /56. That 
is already an operation that must be specified.
- inserts routes in its routing table for these prefixes.
- advertises these prefixes in RA.
- when the delegated prefix changes all the above must be updated.

 From a software point of view that is a lof of operations.

 From an interoperability standpoint: forming a /65 out of the /56, and 
putting in RA, could be reasonable, yet only BSD interoperates (not linux).

Alex

> Thanks - Fred
>
> *From:*Alexandre Petrescu [mailto:[email-masked]]
> *Sent:* Thursday, May 31, 2018 2:34 AM
> *To:* Templin (US), Fred L <[email-masked]>
> *Cc:* [email-masked]
>     *From:*v6ops [mailto:[email-masked]] *On Behalf Of
>     *Alexandre Petrescu
>     *To:* [email-masked] <mailto:[email-masked]>
>     even though it _does_ request and obtain a prefix P and does RA it
>     to other nodes in the network in controls.
>
>                                         x
>
>                                         |
>
>                           upstream link |
>
>                                         |
>
>                              +----------+----------+
>
>                              |  upstream interface |
>
>                              +--+-+--+-+--+-----+--+
>
>                              |                     |
>
>                              | requesting node 'R' |
>
>                              |                     |
>
>                              +---------------------+
>
>       
>
>       
>
>       
>
>       
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 31 May 2018 16:36:44 +0000

HI Alex,

OK, but what you are articulating still falls under the Classic Routing Model
in Figure 1. The supporting text there currently says:

   “ 'R' assigns addresses 'A(*)' taken from 'P' to downstream interfaces, and hosts 'H(i)'
    on downstream networks assign addresses 'A(*)' taken from 'P' to their interface
    attachments to the downstream link. 'R' then acts as a router for hosts 'H(i)' on
    downstream networks and as a host on behalf of its local applications, i.e., the same
    as for any router. (This model additionaly supports recursive prefix sub-delegation to
    other requesting routers more deeply embedded in the downstream network, e.g.,
   sub-delegation of a /48 into multiple /56 prefixes, sub-delegation of a /56 into multiple
    /60 prefixes, etc.).”

It seems to me that the final sentence already articulates what you are looking
for in terms of prefix sub-delegation, but the initial sentence seems to require
the router to assign addresses taken from ‘P’ to one of its interfaces and this
is where your comment applies.

How does this look for a proposed rewrite:

   “ 'R' assigns at least one globally-unique address to an interface (e.g., to support error
    reporting, network management, etc.), where the address(es) may be taken from ‘P’,
    configured via SLAAC from a PIO received in an RA message received on an upstream
    interface, manually configured, etc. ‘R’ then assigns zero or more addresses 'A(*)' taken
    from 'P' to downstream interfaces, and advertises sub-prefixes taken from ‘P’ in RA
    message PIO options to hosts 'H(i)' on downstream networks. 'R' then acts as a router
    for hosts 'H(i)' on downstream networks and as a host on behalf of its local applications,
    i.e., the same as for any router. (This model additionaly supports recursive prefix sub-
    delegation to other requesting routers more deeply embedded in the downstream
    network, e.g., sub-delegation of a /48 into multiple /56 prefixes, sub-delegation of a
    /56 into multiple /60 prefixes, etc.).”

Comments?

Thanks - Fred

From: Alexandre Petrescu [mailto:[email-masked]]
Sent: Thursday, May 31, 2018 8:36 AM
To: Templin (US), Fred L <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] IPv6 Prefix Delegation Models ('draft-templin-v6ops-pdhost') - draft update

In this particular little case the node reveives a delegated prefix _and_ advertises it in RA further down.  YEt it does not use it to form any address for itself.
In order to form an address for itself the node uses the prefix received in the RA from the cellular network (not from DHCP PD).

I agree.

But is the case of not

It is not "not doing anything at all with the delegated prefix".  It does several things with the delegated prefix:
- derives sub-prefixes out of it, making seveal /64s out of a /56.  That is already an operation that must be specified.
- inserts routes in its routing table for these prefixes.
- advertises these prefixes in RA.
- when the delegated prefix changes all the above must be updated.

From an interoperability standpoint: forming a /65 out of the /56, and putting in RA, could be reasonable, yet only BSD interoperates (not linux).

Alex

Thanks - Fred

From: Alexandre Petrescu [mailto:[email-masked]]
Sent: Thursday, May 31, 2018 2:34 AM
To: Templin (US), Fred L <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] IPv6 Prefix Delegation Models ('draft-templin-v6ops-pdhost') - draft update

Hi Fred,

Alex

Thanks - Fred

                                   x

                                   |

                     upstream link |

                                   |

                        +----------+----------+

                        |  upstream interface |

                        +--+-+--+-+--+-----+--+

                        |                     |

                        | requesting node 'R' |

                        |                     |

                        +---------------------+

                                   x

                                   |

                     upstream link |

                                   |

                        +----------+----------+

                        |  upstream Interface |

                        +---------------------+

                        |                     |

                        | requesting node 'R' |

                        |                     |

                        +--+-+--+-+--+-----+--+

                        |A1| |A2| |A3| ... |An|

                        +--+-+--+-+--+-----+--+

                        |  virtual Interface  |

                        +---------------------+

                                   x

                                   |

                     upstream link |

                                   |

                        +----------+----------+

                        |  upstream interface |

                        +--+-+--+-+--+-----+--+

                        |A1| |A2| |A3| ... |An|

                        +--+-+--+-+--+-----+--+

                        |                     |

                        | requesting node 'R' |

                        |                     |

                        +---------------------+

                        |   virtual interface |

                        +---------------------+

v6ops mailing list