Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-03.txt

["Fred Baker (fred)" <[e-mail]>]

In the following, I am speaking as a member of the community. I expect other members of the community to chime in.

The "Strong" and "Weak" host models are defined in section 3.3.4.2  "Multihoming Requirements", and not in the part which is normative, but the "discussion" presented to assist in understanding. The requirements stated have to do with the choice of a source address, and consist of:

            The following general rules apply to the selection of an IP
            source address for sending a datagram from a multihomed
            host.

            (1)  If the datagram is sent in response to a received
                 datagram, the source address for the response SHOULD be
                 the specific-destination address of the request.  See
                 Sections 4.1.3.5 and 4.2.3.7 and the "General Issues"
                 section of [INTRO:1] for more specific requirements on
                 higher layers.

                 Otherwise, a source address must be selected.

            (2)  An application MUST be able to explicitly specify the
                 source address for initiating a connection or a
                 request.

            (3)  In the absence of such a specification, the networking
                 software MUST choose a source address.  Rules for this
                 choice are described below.

            There are two key requirement issues related to multihoming:

            (A)  A host MAY silently discard an incoming datagram whose
                 destination address does not correspond to the physical
                 interface through which it is received.

            (B)  A host MAY restrict itself to sending (non-source-
                 routed) IP datagrams only through the physical
                 interface that corresponds to the IP source address of
                 the datagrams.

Personally, I will note that the socket library doesn't provide for the application to select the source address it will use. There are ways around that, but generally speaking, the source address is chosen by the underlying communication layers.

The Strong and Weak models, there called "ES" or End System models, have to do with the interpretation of "MAY" in requirements A and B. In the Strong ES Model, MAY becomes MUST, and in the Weak ES Model, and MAY becomes MUST NOT. In the words of the RFC, A Strong ES emphasizes the distinction between a host and a router, and a Weak ES de-emphasizes that distinction. A Strong ES, in selecting a router (which it alternately calls an "IS" or a "gateway") the host performs a function

                         route(src IP addr, dest IP addr, TOS)
                                                        -> gateway

And a weak ES performs a function

                         route(dest IP addr, TOS) -> gateway, interface

The scope of this draft has to do with the number of addresses assigned or potentially assigned to the host. There are two obvious examples of the implications here.

One a fairly standard behavior of Windows, Mac, FreeBSD and Linux systems today, which is that when a router announced a SLAAC prefix in an RA, the host creates one "permanent" address, and in a rolling manner, creates and destroys a "temporary" address every day, with up to seven valid at any given time. It expects to announce the "permanent" address in DNS for the benefit of other systems desiring to communicate with it, and to originate sessions using its various "temporary" addresses. If it has ten interfaces and receives three separate RAs on each, it potentially has 30=10*3 prefixes announced to it, and it might have 240=30*8 active addresses at any given time.

The assumption made in draft-ietf-6man-multi-homed-host is that the host acts as a "strongish" host with respect to each of those prefixes. The difference between its model and RFC 1122's Strong Host model is, in a word, MIF; in selecting a first hop gateway, it might find that gateway on multiple interfaces.

The other is something we know some industry leaders to be experimenting with (draft-herbert-nvo3-ila), which is that DHCP-PD is used to allocate a prefix to a physical or virtual host. The implication of having done so is that the host has 2^64 addresses, which it may use in any way it chooses. If the host is multihomed (e.g., has more than one L2 interface), one has to assume that the routing system somehow knows to route traffic to that prefix to any of its interfaces, and one can expect the host itself to operate as a weak host – it will pump packets out whatever interface it chooses, and they will all be in that prefix. And BTW, there is no architectural reason it has to be exactly one prefix.

As someone noted to me yesterday in FB messaging, the question there becomes at what point we re-introduce the address exhaustion problem into IPv6. When do we find ourselves dealing out inefficiently used large blocks of addresses in such a willy-nilly manner that we actually start running out of prefixes to allocate? We have, nominally, 2^64 /64 prefixes we can allocate. When does that become a small number?


When I consider the implications of the Strong and Weak ES Models for this draft, I am forced to choose words that apply in both of these cases. From my perspective, speaking not as chair (which is a procedural role) but as an individual contributor (which is a technical role), my question becomes how to to further the scope of the draft without adding undue complexity or making the statement be about one paradigm or the other.

You're thinking, at this point, "Fred, this is one !@#$ of a long email! TL;DR!". Yes, and we can do that to this draft as well. I don't think that is a useful direction.

So, speaking as an individual contributor, I think the direction to go is simplicity. In both of the cases, what the draft targets is "when allocating addresses using DHCP/DHCPv6, please don't limit me to a single /128". The statement applies in both cases equally well. Introducing the Strong vs Weak ES Model discussion adds text to the draft, but I'm not sure it adds understanding to a BCP. Hence, I personally would leave the model discussion to another draft, and focus on the stated objective of the proposed Best Current Practice.


From: "Templin, Fred L" <[e-mail]<mailto:[e-mail]>>
Date: Friday, December 11, 2015 at 8:44 AM
To: Fred Baker <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Lorenzo Colitti <[e-mail]<mailto:[e-mail]>>
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-03.txt

Hi Fred,

I think I need the community’s help in understanding the tradeoffs for strong vs. weak
end system models in terms of the behavior hosted applications will observe before I
can comment further. As I understand it, when a PD prefix is received over a common
interface type such as multicast-capable (call it “eth0”), but addresses from the PD
prefix are assigned to an internal virtual interface (call it “lo0”) applications will observe
packets arriving with a destination address other than the ones assigned to the
interface the packet arrived on. That is the weak end system model. If we could
somehow assign the addresses to “eth0”, it then becomes strong end system.

But, the question is whether weak end system is a bad thing, and is it worth taking
measures to present the application with a strong end system model? This is where
I think we need the help of community – especially app developers – to understand
the tradeoffs. What is it that apps expect to see?

Thanks – Fred
[e-mail]<mailto:[e-mail]>

From: Fred Baker (fred) [mailto:[e-mail]]
Sent: Thursday, December 10, 2015 11:22 PM
To: Templin, Fred L
Cc: [e-mail]<mailto:[e-mail]>; Lorenzo Colitti
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-03.txt

Fred, to be honest, this is getting pretty marginal with respect to the scope of the draft. Lorenzo has stated that he considers it out of scope, and at first blush I would agree – the scope is about the number of addresses that get assigned when at least one gets assigned (whether to an interface or a system), not an update to RFC 4862 on the use of DAD.

If you think the scope needs to include DAD and the strong and weak host models, I think you need to support the argument.

From: v6ops <[e-mail]<mailto:[e-mail]>> on behalf of Lorenzo Colitti <[e-mail]<mailto:[e-mail]>>
Date: Thursday, December 10, 2015 at 8:46 AM
To: "Templin, Fred L" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-03.txt

On Fri, Dec 11, 2015 at 1:36 AM, Templin, Fred L <[e-mail]<mailto:[e-mail]>> wrote:
But, addresses
could also be assigned to the interface over which the prefix is received as long as the prefix itself is not added to the prefix list for that interface

No, that's a violation of section 1 of RFC 4862, which says:

   To ensure that all configured addresses are likely to be unique on a
   given link, nodes run a "duplicate address detection" algorithm on
   addresses before assigning them to an interface.  The Duplicate
   Address Detection algorithm is performed on all addresses,
   independently of whether they are obtained via stateless
   autoconfiguration or DHCPv6.

The text in the address availability draft is careful not to violate the text above; it does so by saying that DAD can be avoided if the address is not assigned to the physical interface.

I wrote this draft as a backup in case the subject would not be fully covered
in your document, but it appears that you are now willing to provide coverage.

I think it's fine to mention in passing (as we now do), but I think a more detailed description is out of scope. This document is about recommendations on assigning multiple addresses to to hosts, not how the hosts configure the addresses that they get.