Subject: Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 1 May 2018 19:46:47 +0200

Le 30/04/2018 à 22:58, Joe Touch a écrit :
> 
> 
> On 2018-04-30 16:06, Templin (US), Fred L wrote:
> 
>> Hi Joe/Fred,
>>
>> A comment on one point that was made:
>>
>> >Although there can be addresses assigned to a "node" rather than an interface,
>>
>> I always understood that addresses were assigned to an interface,
>>
>> even if only a loopback or other internal virtual interface.
>>
> They strictly don't need to be assigned to an interface at all, except 
> as an artifact of how certain OSes are designed.

In some case, yes.  I know a Home Address (Mobile IP protocol) is put in 
a configuration file of the node and is not assigned to any of its 
interfaces.  The Care-of Address is assigned to real interface.

In some other Mobile IP case the Home Address is assigned to a virtual 
interface.

Alex

> 
> I.e., you can assign one to "the node" that is not assigned to an 
> interface, so that it would be used as a source address only when 
> explicitly indicated by the application or as a reply to that address 
> (and never, e.g., as a side effect of 1122 forwarding lookup).
> 
>> An
>>
>> address (or prefix) can be delegated to the node, but until the
>>
>> node assigns the addresses to an interface they are unreachable.
>>
>> And, if the node receives packets with destination addresses that
>>
>> are unassigned it can either send a Destination Unreachable, or
>>
>> just let it black hole. Do I have this right?
>>
> They may be unreachable from L2 packets received on an addressed LAN, 
> but they would be reachable from unnumbered pt-pt interfaces or via 
> decapsulation (again, depending on how the OS implements tunnels).
> 
> Yes, it's simpler in most current OSes do assign these to an interface 
> (at least a virtual interface), but it isn't strictly required.
> 
> For IPv6, this would require a way to assign an address that was NOT a 
> direct effect of receiving an RA message, but that's permitted.
> 
> Joe
> 
>> Thanks - Fred
>>
>> *From:*v6ops [mailto:[email-masked]] *On Behalf Of *Joe Touch
>> *Sent:* Monday, April 30, 2018 9:03 AM
>> *To:* Fred Baker <[email-masked]>
>> *Cc:* V6 Ops List <[email-masked]>
>> *Subject:* Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101
>>
>> On 2018-04-29 20:09, Fred Baker wrote:
>>
>>     On Apr 28, 2018, at 9:41 PM, Fred Baker <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>         3. Does the answer to 2. depend on the weak-host, strong-host
>>         distinction?
>>
>>
>>     Speaking for myself, and hats off, I think the
>>     weak-host/strong-host distinction isn't currently an accurate
>>     depiction of how hosts or routers work in 2018, and isn't an
>>     obvious choice for a virtualized system. I refer to RFC 1122,
>>     section 3.3.4.2,  Multihoming Requirements, which has to do with
>>     the choice of source address from a host with more than one interface.
>>
>> IMO, Internet nodes are inherently weak-host at the IP layer and 
>> strong-host at the link layer.
>>
>> The weak-host part is validated, as you note, by RFC 1122.
>>
>> The strong-host part is validate, AFAICT, by ARP and neighbor discovery.
>>
>> Although there can be addresses assigned to a "node" rather than an 
>> interface, the distinction is philosophical at best; as you point out, 
>> all addresses are effectively virtual interfaces anyway - and those 
>> interfaces are defined in the context of the network over which they 
>> reach other interfaces.
>>
>> Joe
>>
> 
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 1 May 2018 19:54:29 +0200

Le 01/05/2018 à 03:27, Fred Baker a écrit :
> [SECURITE : MISE EN QUARANTAINE DES PIECES JOINTES POTENTIELLEMENT
> DANGEREUSES]
> 
> Ce message contient des pieces jointes potentiellement dangereuses
> car susceptibles de contenir des virus. Pour lutter contre
> l'expansion de ce type d'attaque, les documents [null] ont ete
> retires du message original ci-dessous. Pour les documents Office, le
> CEA recommande l'usage exclusif des formats plus recents exempts de
> macros comme DOCX, XLSX, PPTX, merci de le signaler a votre
> expediteur.
> 
> Pour de plus amples informations ou pour connaitre les mecanismes de
> mise en quarantaine, vous pouvez vous rapprocher de votre service
> informatique ou consulter le site USCIpedia - rubrique PureMessage.
> 
> ----------------MESSAGE ORGINAL ci-dessous------------------
> 
> 
> 
>> On Apr 30, 2018, at 4:06 PM, Templin (US), Fred L
>> <[email-masked]> wrote:
>> 
>> even if only a loopback or other internal virtual interface. An 
> Ole and Joe already replied. I'd be interested in comments from
> people that have deployed the allocation of a prefix to a node. My
> understanding is that the address is assigned to a virtual interface
> used by a container or whatever. When people talk about assigning one
> to an application (which I have also heard), I tend to think they are
> using it as a combination of an address (get the packet to the
> destination node) and a port (deliver the packet to a transport
> session or application). At that point, it diverges a bit from the
> historic "address on an interface" model in the sense that the
> interface isn't completely obvious.

I agree.

In my trial, the /56 prefix that is obtained with DHCPv6 Prefix 
Delegation is used to form other /64 prefixes (Px).  These Px are put in 
RAs whose receivers form addresses.  The IoT Router does not form an 
address out of any Px.

That /56 prefix is not assigned on any interface nor to any application.

But I agree it is very well possible to assign an IPv6 address to some 
application or to some configuration file, or to some virtual machine; 
it is not mandatory to assign an IPv6 address to an interface.

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 1 May 2018 20:00:38 +0200

Le 30/04/2018 à 02:09, Fred Baker a écrit :
> On Apr 28, 2018, at 9:41 PM, Fred Baker <[email-masked]>
> wrote:
> Speaking for myself, and hats off, I think the weak-host/strong-host
> distinction isn't currently an accurate depiction of how hosts or
> routers work in 2018, and isn't an obvious choice for a virtualized
> system. I refer to RFC 1122, section 3.3.4.2,  Multihoming
> Requirements, which has to do with the choice of source address from
> a host with more than one interface.
> 
> The rules given are that (1) if the packet is being sent in response
> to a packet received, it MUST use the destination address in that
> packet as its source address, (2) it MUST be possible for the
> application to specify the source address, and (3) if neither (1) nor
> (2) apply, the communication layers below the application MUST (as
> in, "are forced to") select a source address. As additional
> considerations, (A) a host MAY discard a packet received on a
> physical interface other than that which its destination address is
> used on, and (B) a host MAY restrict itself to sending datagrams from
> the interface configured with whatever source address it uses.
> 
> The document then continues with "discussion", which to my thinking
> is the most interesting part of RFC 1122, 1123, and 1812, which has
> to do with "why". The "Weak ES model" and the "Strong ES model" are
> found in that discussion, and are explicitly non-normative.
> 
> In the Strong ES model, The Strong ES (End System, i.e., host) model 
> emphasizes the host/gateway (ES/IS) distinction, and would therefore
> substitute MUST for MAY in issues (A) and (B) above.  It tends to
> model a multihomed host as a set of logical hosts within the same
> physical host.
> 
> In other words, (A) a host MUST discard a packet received on a
> physical interface other than that which its destination address is
> used on, and (B) a host MUST restrict itself to sending datagrams
> from the interface configured with whatever source address it uses.
> 
> Note that this model logically requires that in general there be at
> least one default gateway, and preferably multiple defaults, for each
> IP source address.
> 
> The Weak ES Model de-emphasizes the ES/IS distinction, and would
> therefore substitute MUST NOT for MAY in issues (A) and (B).  This
> model may be the more natural one for hosts that wiretap gateway
> routing protocols, and is necessary for hosts that have embedded
> gateway functionality.
> 
> In other words, (A) a host MUST NOT discard a packet received on a
> physical interface other than that which its destination address is
> used on, and (B) a host MUST NOT restrict itself to sending datagrams
> from the interface configured with whatever source address it uses.
> 
> 
> The question Fred is asking has to do with "end systems that receive
> a prefix delegation", and whether we would call such a one a host, a
> router, a node, or something else.

IMHO it should be called a router.

A Host does not need more than the RA it receives.

A 'node' is an ambiguous Host or Router.

I also agree that a prefix delegation operation could be something else 
than DHCPv6-PD, or complimentary to it.

Just runnin DHCPv6-PD is not sufficient to make a router work with a 
delegated prefix.  One also needs a method to form sub-prefixes, to keep 
track of them, and more.  DHCPv6-PD does not do these and others.

Alex

>> From my perspective, if a prefix is assigned to a chassis for use
>> in addressing its applications, containers, virtual hosts, or
>> whatever, it is not assigned to an interface per se. It is best
>> thought of as having been assigned to a network that in some sense
>> lies "behind" a router, comparable to having been assigned to a
>> home or other network through the CPE that connects to the upstream
>> network. So any discussion of the prefix being "on an interface"
>> isn't visible to that upstream network. There is an address there,
>> of course, which may be only a link-local address, and in the
>> upstream router is primarily used as the next hop in the route
>> toward the prefix in question. Whether it as available for network
>> management purposes is not specified; if it is a global address, it
>> might be used for network management purposes, and if it is
>> link-local, the network management application would have to be on
>> the same LAN for that to work. I would expect, rather, that network
>> management is done via some application in the same chassis,
>> perhaps in a container or virtual host. Yes, that address would be
>> used in network management messages on the interface in question;
>> if the chassis had multiple physical interfaces, it might also be
>> used on them.
> 
> In other words, the weak and strong ES models are inadequate to
> describe a chassis allocated a prefix. It is a case not discussed in
> currently-published RFCs.
> 
> What do we call such a chassis? I call it a chassis. It would be
> valid to call it a node, although from a networking perspective it
> contains multiple virtualized nodes. It is not, in my view, exactly a
> host (a system with an address on one or more interfaces and
> responding only packets sent to one of those addresses), nor is it
> exactly a router (a system that receives messages sent to an address
> not configured on one of its interfaces and forwarding it toward
> another system, the indicated host); it is a third category. That
> category is a set of systems that contain one or more identifiable
> routers and MAY contain one or more identifiable hosts, in some
> virtualized sense.
> 
> 
>

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Tue, 1 May 2018 20:59:30 +0000

> IMHO it should be called a router.
[[Dusan]] Do you envision a delegated prefix being assigned to a host?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 2 May 2018 08:33:01 +0200 (CEST)

On Mon, 30 Apr 2018, Fred Baker wrote:

> Ole and Joe already replied. I'd be interested in comments from people 
> that have deployed the allocation of a prefix to a node. My

I have seen discussions on how to make web servers get IPv6 address ranges 
without having to set "listen" for each individual IPv6 address in that 
range. Same thing with docker containers, which might today be implemented 
with interface semantics, but this is not necessarily needed, it's just 
the way it has to be done right now.

So going forward, perhaps we'll see "routing" with "destinations" being a 
socket, or some new construct in some new API that hasn't been designed 
yet. Is this an "interface"? I don't know.

Having to create interfaces and addresses for each application, binding to 
individual sockets for each address etc, that doesn't seem to scale 
(keeping huge data structs and matching things within these doesn't seem 
to make sense when one really wants to use the entire range) Instead an 
application (which can be a container for instance) should be "routed" 
this space, and know about it by being told this range of addresses.

This is why I support prefix delegation of different kinds, and it should 
not only be DHCPv6-PD. I see no upside in running an DHCPv6 client in the 
docker container, when all information it needs is what prefix it has and 
where to expect these packets. Even running RA/ND here is no great upside.

https://docs.docker.com/v17.09/engine/userguide/networking/default_network/ipv6/#how-ipv6-works-on-docker

It seems to me that they're trying to do what Fred T is trying to do, but 
within a "host" (whatever that is). Can we come up with a way of doing 
this that requires the least amount of code and is re-usable both for 
within and between devices (if we need to make this distinction)?

It seems to me that the docker people have done the best they can with 
current tools, and it shows that the tools are lacking. So I fully support 
Fred Templin in his quest of making this simpler/faster, I would just like 
to not have to tunnel DHCP packets within ND/RA packets and thus have 
everybody figure out how to unwrap this and give it to DHCP codebase, 
requiring to have these two applications at the same time.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 2 May 2018 11:10:50 +0200

> [[Dusan]] Do you envision a delegated prefix being assigned to a host?

In principle no, I do not.

The main scenario I am concerned with is an IoT Router that needs to
give access always to some IP devices attached to it. It is an
in-vehicle network.

But, other people may need a smartphone computer to act as a Host most
of the time. And some times (not always) to tether.

Alex

---

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

Hi Dusan and Alex,

We are using prefix delegation to delegate IPv6 prefixes over a VPN to
cellphones that have cellular and WiFi interfaces. The VPN interface
"rides over" the underlying physical interfaces, and we assign addresses
taken from the  prefix to the VPN interface.

Using Fred's idea, though, if the implementation allowed we could assign
the addresses to applications on the cellphone instead of to the VPN
interface. AFAICT, existing implementations do not currently allow that,
but it certainly seems like something that could be implemented.

Either way, though, the cellphone acts as a host and not a router.

Thanks - Fred

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
> Sent: Wednesday, May 02, 2018 2:11 AM
> To: Mudric, Dusan (Dusan) <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101
> 
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 3 May 2018 09:03:33 +0200

> taken from the  prefix to the VPN interface.

In this sense, this sole VPN interface makes this 'rider' machine be a
Host, despite the presence of multiple physical interfaces in the
'under'-machine.

I would like to ask you: for which reason was DHCPv6-PD used, instead of
RA sent by the 'rider' machine present on the other end of the VPN
interface?

(and I do agree that prefix delegation can also be necessary for a Host,
not only for a Router, when there are so many interfaces, machine
instances, each potentially in a need of a distinct /64).

Alex

---

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

Hi Alex,

> From: Alexandre Petrescu [mailto:[email-masked]]
> Sent: Thursday, May 03, 2018 12:04 AM
> To: Templin (US), Fred L <[email-masked]>; Mudric, Dusan (Dusan) <[email-masked]>
> Cc: [email-masked]

We already use RS/RA as discussed in 'draft-templin-6man-dhcpv6-ndopt'.
According to that draft, the RS/RA messages can contain DHCPv6 PD options,
or they can contain some other form of Prefix Delegation signaling that is yet
to be specified. But, again, it is based on RS/RA and the actual PD signaling
embedded in the RS/RA can be - but need not be - DHCPv6.

> instances, each potentially in a need of a distinct /64).

OK, thanks.

Fred

---

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

Hi Fred,

> What do we call such a chassis? I call it a chassis.

In my industry, we call it a "platform". A platform can be anything from an airplane
to a cellphone to a drone to a laptop computer to an automobile to a high-end
router, to a VM to, etc. etc.

Platform is a generic term that can be applied to any type of device that might
ever want to receive a prefix delegation. I understand your chassis comment,
but to me it sounds a bit too automotive-centric. So, instead of host, router,
node, etc. we could refer to them as platforms.

Thanks - Fred

> From: v6ops [mailto:[email-masked]] On Behalf Of Fred Baker
> Sent: Sunday, April 29, 2018 5:09 PM
> To: V6 Ops List <[email-masked]>
> On Apr 28, 2018, at 9:41 PM, Fred Baker <[email-masked]> wrote:
> > 3. Does the answer to 2. depend on the weak-host, strong-host distinction?
> 
> Speaking for myself, and hats off, I think the weak-host/strong-host distinction isn't currently an accurate depiction of how hosts or
> routers work in 2018, and isn't an obvious choice for a virtualized system. I refer to RFC 1122, section 3.3.4.2,  Multihoming
> Requirements, which has to do with the choice of source address from a host with more than one interface.
> 
> The rules given are that (1) if the packet is being sent in response to a packet received, it MUST use the destination address in that
> packet as its source address, (2) it MUST be possible for the application to specify the source address, and (3) if neither (1) nor (2)
> apply, the communication layers below the application MUST (as in, "are forced to") select a source address. As additional
> considerations, (A) a host MAY discard a packet received on a physical interface other than that which its destination address is used
> on, and (B) a host MAY restrict itself to sending datagrams from the interface configured with whatever source address it uses.
> 
> The document then continues with "discussion", which to my thinking is the most interesting part of RFC 1122, 1123, and 1812, which
> has to do with "why". The "Weak ES model" and the "Strong ES model" are found in that discussion, and are explicitly non-normative.
> 
> In the Strong ES model,
>                       The Strong ES (End System, i.e., host) model
>                       emphasizes the host/gateway (ES/IS) distinction,
>                       and would therefore substitute MUST for MAY in
>                       issues (A) and (B) above.  It tends to model a
>                       multihomed host as a set of logical hosts within
>                       the same physical host.
> 
> In other words, (A) a host MUST discard a packet received on a physical interface other than that which its destination address is used
> on, and (B) a host MUST restrict itself to sending datagrams from the interface configured with whatever source address it uses.
> 
>                       Note that this model logically requires that in
>                       general there be at least one default gateway, and
>                       preferably multiple defaults, for each IP source
>                       address.
> 
> The Weak ES Model
>                       de-emphasizes the ES/IS distinction, and
>                       would therefore substitute MUST NOT for MAY in
>                       issues (A) and (B).  This model may be the more
>                       natural one for hosts that wiretap gateway routing
>                       protocols, and is necessary for hosts that have
>                       embedded gateway functionality.
> 
> In other words, (A) a host MUST NOT discard a packet received on a physical interface other than that which its destination address is
> used on, and (B) a host MUST NOT restrict itself to sending datagrams from the interface configured with whatever source address it
> uses.
> 
> 
> The question Fred is asking has to do with "end systems that receive a prefix delegation", and whether we would call such a one a
> host, a router, a node, or something else.
> 
> 
> From my perspective, if a prefix is assigned to a chassis for use in addressing its applications, containers, virtual hosts, or whatever, it is
> not assigned to an interface per se. It is best thought of as having been assigned to a network that in some sense lies "behind" a
> router, comparable to having been assigned to a home or other network through the CPE that connects to the upstream network. So
> any discussion of the prefix being "on an interface" isn't visible to that upstream network. There is an address there, of course, which
> may be only a link-local address, and in the upstream router is primarily used as the next hop in the route toward the prefix in
> question. Whether it as available for network management purposes is not specified; if it is a global address, it might be used for
> network management purposes, and if it is link-local, the network management application would have to be on the same LAN for
> that to work. I would expect, rather, that network management is done via some application in the same chassis, perhaps in a
> container or virtual host. Yes, that address would be used in network management messages on the interface in question; if the
> chassis had multiple physical interfaces, it might also be used on them.
> 
> In other words, the weak and strong ES models are inadequate to describe a chassis allocated a prefix. It is a case not discussed in
> What do we call such a chassis? I call it a chassis. It would be valid to call it a node, although from a networking perspective it contains
> multiple virtualized nodes. It is not, in my view, exactly a host (a system with an address on one or more interfaces and responding
> only packets sent to one of those addresses), nor is it exactly a router (a system that receives messages sent to an address not
> configured on one of its interfaces and forwarding it toward another system, the indicated host); it is a third category. That category is
> a set of systems that contain one or more identifiable routers and MAY contain one or more identifiable hosts, in some virtualized
> sense.

---

From: Ole Troan <[email-masked]>
Date: Thu, 3 May 2018 19:32:22 +0200

> On 3 May 2018, at 17:19, Templin (US), Fred L <[email-masked]> wrote:
> 
> Hi Fred,
> 

We already have a name in IPv6. We call them nodes. 

Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 4 May 2018 08:37:03 +1200

> We already have a name in IPv6. We call them nodes. 

Due to virtualisation, nodes may contain nodes, recursively. Each node may
contain multiple (virtual) interfaces. I think that explains some of the confusion.

   Brian

---

From: Joe Touch <[email-masked]>
Date: Thu, 03 May 2018 17:50:13 -0400

> contain multiple (virtual) interfaces. I think that explains some of the confusion.

It really shouldn't. 

Ultimately, the role of any component (physical or virtual) ought to be
very clear in the context of any given network virtualization layer. 

- if it sources or sinks IP packets within that layer with an address it
has been assigned, it is a HOST 

- if it relays information within that layer without consideration of
the IP header, it is a LINK (or link layer/link network) 

- if it relays information within that layer based on the IP header, it
is a ROUTER 

HOST, LINK, and ROUTER are always defined only in the context of a
single virtual/real layer anyway. 

(and yes, a device that relays based IP headers that also sources/sinks
IP packets, such as when a routing device both forwards and supports
remote login or SNMP, then it is *both* a HOST and a ROUTER. I.e.,
generally, routing devices cannot participate in routing protocols
without also being HOSTS.) 

Joe

---

From: Mark Smith <[email-masked]>
Date: Thu, 03 May 2018 21:54:29 +0000

On Sun., 29 Apr. 2018, 14:41 Fred Baker, <[email-masked]> wrote:

> At IETF 101, Fred Templin presented draft-templin-v6ops-pdhost. The draft
> is at https://tools.ietf.org/html/draft-templin-v6ops-pdhost, and his
> presentation deck is at
> https://datatracker.ietf.org/meeting/101/materials/slides-101-v6ops-ipv6-prefix-delegation-models-00
> .
>
> I would like to invite discussion.
>
> In the deck, he asks three questions:
> 1. Do we want to remain prefix delegation service agnostic, or focus on
> one specific service (e.g., DHCPv6-PD)?
> 2. What do we call end systems that receive a prefix delegation? Host?
> Router? Node?
>

The RFC8200 definition of a router is:

"a node that forwards IPv6 packets not explicitly

                addressed to itself."

so these qualify as hosts.

I don't think so.

Strong host/weak host is about how strict a host is about accepting host
owned addresses on interfaces that aren't configured with these addresses.

WH/SH does have an influence though in this scenario.

If the host follows SH, then the delegated prefix has to be assigned to the
interface over which the host will receive packets, otherwise it will
ignore them.

That means the host would by default also respond to ND NSes for any
address within the prefix from devices attached to that link. I think
there's an ND/NUD DoS attack opportunity in that scenario.

This is assuming that other devices somehow  know that the delegated prefix
is on-link. An attacker could effectively assert that through their tool
regardless of the network's view.

WH would be a safer option because the prefix is effectively assigned to an
internal interface.

Regards,
Mark.

> You are welcome, of course, to also raise any other questions or concerns.
>
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 4 May 2018 15:14:54 +0000

Hi Mark,

>That means the host would by default also respond to ND NSes for any address within the prefix from devices attached to that link. I think there's an ND/NUD DoS attack opportunity in that scenario.

This could perhaps be made more clear, but only individual addresses are assigned
to the interface over which the delegated prefix was received; the delegated prefix
itself is not assigned to the interface (or, in the language of RFC4861, is not added
to the prefix list of the receiving interface). So, any ND/NUD messaging for bogus
addresses would simply be dropped and not responded to. Does that help clarify?

Thanks - Fred

From: v6ops [mailto:[email-masked]] On Behalf Of Mark Smith
Sent: Thursday, May 03, 2018 2:54 PM
To: Fred Baker <[email-masked]>
Cc: v6ops list <[email-masked]>
Subject: Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101

On Sun., 29 Apr. 2018, 14:41 Fred Baker, <[email-masked]<mailto:[email-masked]>> wrote:
At IETF 101, Fred Templin presented draft-templin-v6ops-pdhost. The draft is at https://tools.ietf.org/html/draft-templin-v6ops-pdhost, and his presentation deck is at https://datatracker.ietf.org/meeting/101/materials/slides-101-v6ops-ipv6-prefix-delegation-models-00.

In the deck, he asks three questions:
1. Do we want to remain prefix delegation service agnostic, or focus on one specific service (e.g., DHCPv6-PD)?
2. What do we call end systems that receive a prefix delegation? Host? Router? Node?

                addressed to itself."

I don't think so.

Strong host/weak host is about how strict a host is about accepting host owned addresses on interfaces that aren't configured with these addresses.

If the host follows SH, then the delegated prefix has to be assigned to the interface over which the host will receive packets, otherwise it will ignore them.

That means the host would by default also respond to ND NSes for any address within the prefix from devices attached to that link. I think there's an ND/NUD DoS attack opportunity in that scenario.

This is assuming that other devices somehow  know that the delegated prefix is on-link. An attacker could effectively assert that through their tool regardless of the network's view.

WH would be a safer option because the prefix is effectively assigned to an internal interface.

Regards,
Mark..

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