IPv6 Routing & ND vs. Addressing, (Was: Re: <draft-ietf-6man-rfc4291bis-09.txt>)

[David Farmer]

On Sat, Jul 8, 2017 at 3:35 PM, Brian E Carpenter <
***@gmail.com> wrote:

> On 08/07/2017 17:47, Lorenzo Colitti wrote:
> > On Tue, Jul 4, 2017 at 5:22 AM, David Farmer <***@umn.edu> wrote:
> >>
> >> Interface Identifiers are 64 bit long except if the first three bits
> >> of the address are 000, or when the addresses are manually
> >> configured, or by exceptions defined in standards track documents.
> >>
> >>
> > I don't think we should say "by exceptions defined in standards track
> > documents". Whatever document wants to allow non-64-bit prefixes should
> > formally update RFC 4291. Anything else will be confusing for
> implementers.
>
> We're trying to find a compromise between excessive rigidity and excessive
> flexibility. I don't see any confusion in the present text: if you've read
> 4291bis and you come upon a standards track document specifying a value
> !=64, you can use it. If you've only read RFC4291, you're out of date.
>
> You can certainly argue that RFC6164 should have formally updated RFC4291.
>

I don't think a simple statement that is a "compromise between excessive
rigidity and excessive flexibility" is going to work. I think we need a
more nuanced statement that makes clear that address assignment is ridged
at 64 bits, but routing is flexible anywhere between 0 and 128 bits.

Lets step back from RFC4291bis for a moment and look at how IPv6 subnets,
routing, neighbor discovery, SLAAC and addressing are all interrelated.

RFC5942 the IPv6 Subnet Model, says compared to IPv4;

- The behavior of IPv6 as specified in Neighbor Discovery (ND)
[RFC4861] is quite different. The on-link determination is separate
from the address assignment. A host can have IPv6 addresses without
any related on-link prefixes or can have on-link prefixes that are
not related to any IPv6 addresses that are assigned to the host. Any
assigned address on an interface should initially be considered as
having no internal structure as shown in [RFC4291].

- The assignment of an IPv6 address -- whether through IPv6
stateless address autoconfiguration [RFC4862], DHCPv6 [RFC3315],
or manual configuration -- MUST NOT implicitly cause a prefix
derived from that address to be treated as on-link and added to
the Prefix List. A host considers a prefix to be on-link only
through explicit means, such as those specified in the on-link
definition in the Terminology section of [RFC4861] (as modified
by this document) or via manual configuration. Note that the
requirement for manually configured addresses is not explicitly
mentioned in [RFC4861].

RFC4861 Neighbor Discovery (ND), says;

- When sending a packet to a destination, a node uses a combination of
the Destination Cache, the Prefix List, and the Default Router List
to determine the IP address of the appropriate next hop, an operation
known as "next-hop determination". Once the IP address of the next
hop is known, the Neighbor Cache is consulted for link-layer
information about that neighbor.

Next-hop determination for a given unicast destination operates as
follows. The sender performs a longest prefix match against the
Prefix List to determine whether the packet's destination is on- or
off-link. If the destination is on-link, the next-hop address is the
same as the packet's destination address. Otherwise, the sender
selects a router from the Default Router List

- Address resolution is the process through which a node determines the
link-layer address of a neighbor given only its IP address. Address
resolution is performed only on addresses that are determined to be
on-link and for which the sender does not know the corresponding
link-layer address.

- Stateless address autoconfiguration [ADDRCONF] ... may impose
certain restrictions on the prefix length for address configuration
purposes. Therefore, the prefix might be rejected by [ADDRCONF]
implementation in the host. However, the prefix length is still valid
for
on-link determination when combined with other flags in the prefix
option.

RFC7608 IPv6 Prefix Length Recommendation for Forwarding, says;

- Forwarding processes MUST be designed to process prefixes of any
length up to /128, by increments of 1.

RFC4862 IPv6 Stateless Address Autoconfiguration, says;

- If the sum of the prefix length and interface identifier length
does not equal 128 bits, the Prefix Information option MUST be
ignored. An implementation MAY wish to log a system management
error in this case. The length of the interface identifier is
defined in a separate link-type specific document, which should
also be consistent with the address architecture [RFC4291].

It is the responsibility of the system administrator to ensure
that the lengths of prefixes contained in Router Advertisements
are consistent with the length of interface identifiers for that
link type. It should be noted, however, that this does not mean
the advertised prefix length is meaningless. In fact, the
advertised length has non-trivial meaning for on-link
determination in [RFC4861] where the sum of the prefix length and
the interface identifier length may not be equal to 128. Thus, it
should be safe to validate the advertised prefix length here, in
order to detect and avoid a configuration error specifying an
invalid prefix length in the context of address autoconfiguration.

RFC4291 IPv6 Addressing Architecture, say;

- IPv6 unicast addresses are aggregatable with prefixes of arbitrary
bit-length, similar to IPv4 addresses under Classless Inter-Domain
Routing.

- For all unicast addresses, except those that start with the binary
value 000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format.

- A slightly sophisticated host (but still rather simple) may
additionally be aware of subnet prefix(es) for the link(s) it is
attached to, where different addresses may have different values for
n:

| n bits | 128-n bits |
+-------------------------------+---------------------------------+
| subnet prefix | interface ID |
+-------------------------------+---------------------------------+

Though a very simple router may have no knowledge of the internal
structure of IPv6 unicast addresses, routers will more generally have
knowledge of one or more of the hierarchical boundaries for the
operation of routing protocols. The known boundaries will differ
from router to router, depending on what positions the router holds
in the routing hierarchy.

Except for the knowledge of the subnet boundary discussed in the
previous paragraphs, nodes should not make any assumptions about the
structure of an IPv6 address.

----

The fact that RFC4291 uses the term subnet confuses things a lot, but
RFC5942 is quite explicit that the two aspects of a subnet (on-link
determination and address assignment) are split in IPv6. So, I'm going to
use the terms on-link prefix and address assignment prefix as separate
entities, and not the term subnet.

What does all that mean:

- It can be inferred from the 64 bit IID requirement that address
assignment prefixes are
64 bits in length.

- SLAAC assigns 64 bit IIDs and they are combined with 64 bit address
assignment
prefixes.

- Routing and neighbor discovery are both based on on-link prefixes of any
length, up to
128 bits.

- IIDs within an address assignment prefix are not valid neighbors unless
they are also
covered by an on-line prefix.

- Link-local addresses by definition are alway valid neighbors or in other
words the
on-link prefix for link-local is 64 bits by definition.

How is the seeming contradiction between a fixed 64 bit address assignment
prefix and a variable length on-link prefix reconciled?

The easiest way to reconcile this is;

A common 64 bit prefix can be used for both the on-link prefix and the a
ddress
assignment prefix for a link.

However, that is not the only way, another way to reconcile this is to view
it is as constraining which links address assignment prefixes and
on-link prefixes
are associated with.

All 64 bit or longer on-link prefixes must be associated with the same
link as
the covering 64 bit address assignment prefix. And, all of the 64 bit a
ddress
assignment prefixes must be associated with the same link as a covering 63
bit
or shorter on-link prefix.

----

Examples;

1. A link has an address assignment prefix of 2001:db8:1::/64, and on-link
prefix of 2001:db8:1::/64

This one is easy and as humans we like easy, so this is going to be the
most common situation. However;

2. A link has an address assignment prefix of 2001:db8:1::/64, and on-link
prefixes of 2001:db8:1::1:0/112 and 2001:db8:1::2:0/112

So the address 2001:db8:1::4:5 is not on-link in this example. While
2001:db8:1::/64 is assigned to be used for this link, without a covering
on-link prefix 2001:db8:1::4:5 is not a valid neighbor. The assignment
prefix just means that this address would have to be on this link if it was
a valid neighbor, but only on-link prefixes determine what is a valid
neighbor. So, If 2001:db8:1::4:5 were assigned to a node, the node could
use it's link-local address but no other nodes would be able to communicate
with it using the address 2001:db8:1::4:5, again it's not a valid neighbor
because there is no covering on-link prefix.

3. A link has an on-link prefix of 2001:db8:0::/63, and address assignment
prefixes of 2001:db8:0::/64 and 2001:db8:1::/64

In reality this is almost as simple as #1, just summarize the two address
assignment prefixes in to one on-link prefix.

----

A few observations:

Except for RFC4291, most of the specification of IPv6 seem clear that
on-link prefixes are any length 0-128 bits, even SLAAC seems quite specific
that on-link prefixes can be any length. Therefore, it seems unlikely that
RFC4291's specification of 64 bit IIDs are intended to be interpreted as
saying anything about on-link prefixes or to constrain routing or neighbor
discovery in any way. It seems RFC4291's specification of 64 bit IIDs
should only be interpreted as constraining address assignment and not
on-link determination. Further, this seems consistent with RFC4291's title
"IPv6 Addressing Architecture", therefore the scope of it's statements
should be constrained to address assignment or addressing in general,
unless it specifically says something has a broader scope.

It seems clear from RFC5942 that when a prefix length is specified with a
manual configured address it should be interpreted as an on-link prefix not
an address assignment prefix.

If SLAAC is used with an on-link prefix other than 64 bits, all of the
available IIDs will not be valid neighbors, this likely not consistent the
normal intended use of SLAAC. However, when addresses are assigned with
DHCPv6 or manual configuration, it is seems easily possible consider
on-link prefixes of any length.

Further, the use of a common address assignment prefix and on-link prefix
seems the simplest way to resolve the apparent conflict between a fixed 64
bit address assignment prefix and a variable length on-link prefix, However
this is not required.

Therefore it seems like a good idea to provide general guidance that
"on-link prefixes identical to address assignment prefixes are
recommended", but again this is not required.

----

So, What should we say in RFC4291bis? Personally I'd prefer we eliminate
the term subnet from RFC4291bis, but assuming that won't happen how about
the following;

Currently, IPv6 continues the IPv4 model in that a subnet prefix is
associated with one link. Multiple subnet prefixes may be assigned to the
same link. The relationship between links and IPv6 subnet prefixes differs
from the IPv4 model in that the prefixes used for on-link determination are
separate and may differ from the assigned subnet prefixes. However, on-link
prefixes identical with assigned subnet prefixes are recommended. A prefix
length associated with a manually configured address determines the on-link
prefix associated with the manually configured address. See [RFC5942] "The
IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes" for
more details.


Note: Any on-link prefixes longer than a covering assigned subnet prefix
must be associated with the same link as the assigned subnet prefix. Also,
any assigned subnet prefixes longer than a covering on-link prefix must be
associated with the same link as the on-link prefix.


----

IPv6 unicast routing is based on on-link prefixes of any valid length up to
128 [BCP198], which are not necessarily the same as the subnet prefixes
assigned to a link.


----

When forming or assigning unicast addresses, except those that start with
the binary value 000, Interface IDs are required to be 64 bits long. The
rationale for using 64 bit Interface Identifiers can be found in [RFC7421].

Note: the previous paragraph implies nothing about on-link determination
which as discussed in section 2.1 is separate from subnet assignment in
IPv6.


Throw the rotten vegetables now!

Thanks!




--
===============================================
David Farmer Email:***@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: [phone]
Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================

[Lorenzo Colitti]

On Mon, Jul 10, 2017 at 6:09 AM, David Farmer <***@umn.edu> wrote:

> So, What should we say in RFC4291bis? Personally I'd prefer we eliminate
> the term subnet from RFC4291bis, but assuming that won't happen how about
> the following;
>
> Currently, IPv6 continues the IPv4 model in that a subnet prefix is
> associated with one link. Multiple subnet prefixes may be assigned to the
> same link. The relationship between links and IPv6 subnet prefixes differs
> from the IPv4 model in that the prefixes used for on-link determination are
> separate and may differ from the assigned subnet prefixes. However, on-link
> prefixes identical with assigned subnet prefixes are recommended. A prefix
> length associated with a manually configured address determines the on-link
> prefix associated with the manually configured address. See [RFC5942] "The
> IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes" for
> more details.
>
>
> Note: Any on-link prefixes longer than a covering assigned subnet prefix
> must be associated with the same link as the assigned subnet prefix. Also,
> any assigned subnet prefixes longer than a covering on-link prefix must be
> associated with the same link as the on-link prefix.
>
>
> ----
>
> IPv6 unicast routing is based on on-link prefixes of any valid length up
> to 128 [BCP198], which are not necessarily the same as the subnet prefixes
> assigned to a link.
>
>
> ----
>
> When forming or assigning unicast addresses, except those that start with
> the binary value 000, Interface IDs are required to be 64 bits long. The
> rationale for using 64 bit Interface Identifiers can be found in [RFC7421].
>
> Note: the previous paragraph implies nothing about on-link determination
> which as discussed in section 2.1 is separate from subnet assignment in
> IPv6.
>
>
Thanks for putting this all together. I think it's the best assessment of
the current state of the standards that I've seen so far.

I'm not sure the text covers RFC6164 though; I'm not sure whether current
deployments of /127 meet the "Any on-link prefixes longer than a covering
assigned subnet prefix must be associated with the same link as the
assigned subnet prefix" text. I'd expect many networks to number entirely
separate links using /127s that are all drawn from one covering /64; at
least, I know that I've written addressing plans that do that and are still
in use.

Cheers,
Lorenzo

[David Farmer]

On Sun, Jul 9, 2017 at 9:03 PM, Lorenzo Colitti <***@google.com> wrote:

> On Mon, Jul 10, 2017 at 6:09 AM, David Farmer <***@umn.edu> wrote:
>
>> So, What should we say in RFC4291bis? Personally I'd prefer we eliminate
>> the term subnet from RFC4291bis, but assuming that won't happen how about
>> the following;
>>
>> Currently, IPv6 continues the IPv4 model in that a subnet prefix is
>> associated with one link. Multiple subnet prefixes may be assigned to the
>> same link. The relationship between links and IPv6 subnet prefixes differs
>> from the IPv4 model in that the prefixes used for on-link determination are
>> separate and may differ from the assigned subnet prefixes. However, on-link
>> prefixes identical with assigned subnet prefixes are recommended. A prefix
>> length associated with a manually configured address determines the on-link
>> prefix associated with the manually configured address. See [RFC5942] "The
>> IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes" for
>> more details.
>>
>>
>> Note: Any on-link prefixes longer than a covering assigned subnet prefix
>> must be associated with the same link as the assigned subnet prefix. Also,
>> any assigned subnet prefixes longer than a covering on-link prefix must be
>> associated with the same link as the on-link prefix.
>>
>>
>> ----
>>
>> IPv6 unicast routing is based on on-link prefixes of any valid length up
>> to 128 [BCP198], which are not necessarily the same as the subnet prefixes
>> assigned to a link.
>>
>>
>> ----
>>
>> When forming or assigning unicast addresses, except those that start with
>> the binary value 000, Interface IDs are required to be 64 bits long. The
>> rationale for using 64 bit Interface Identifiers can be found in [RFC7421].
>>
>> Note: the previous paragraph implies nothing about on-link determination
>> which as discussed in section 2.1 is separate from subnet assignment in
>> IPv6.
>>
>>
> Thanks for putting this all together. I think it's the best assessment of
> the current state of the standards that I've seen so far.
>

Glad it was useful.


> I'm not sure the text covers RFC6164 though; I'm not sure whether current
> deployments of /127 meet the "Any on-link prefixes longer than a covering
> assigned subnet prefix must be associated with the same link as the
> assigned subnet prefix" text. I'd expect many networks to number entirely
> separate links using /127s that are all drawn from one covering /64; at
> least, I know that I've written addressing plans that do that and are still
> in use.
>

I agree it doesn't really cover RFC6164, and an exception covering it needs
to be added. However, I wasn't sure how narrow or broad of an exception to
add. This is basically comes back to Brian's question, where is the right
balance point "between excessive rigidity and excessive flexibility".

We could add a very narrowly scoped exception basically adding, "or when
used for point-to-point router links [RFC6164]", or very broad exception,
"or when the addresses are manually configured", or possible something
focused on routers only, "or when used on a link with only routers and not
any hosts."

As you bring up, assigning a bunch of point-to-point router links out of a
single /64 could be quite common. However there are other considerations
too, like router loopback /128s, maybe /126s for point-to-point, or small
networks connecting only routers. I think it could also be quite common to
assign router loopbacks out of a common /64, maybe even the same one as the
point-to-point router links. And then I've seen some networks use /126s to
coincide with /30s for IPv4, instead of /127s with /31s for IPv4. Also, if
you connect a small group of routers but no hosts should you have to use
/64 assigned subnets?

So, what is the right balance? Do we need an RFCs explicitly allowing
/128 router loopbacks and small networks connecting only routers? Or, how
broad of an exception should we make?

Thanks.

--
===============================================
David Farmer Email:***@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: [phone] <(612)%20626-0815>
Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952>
===============================================

[Nick Hilliard]

David Farmer wrote:
> Or, how broad of an exception should we make?

/0 to /128 would work for me.

More seriously, the sentence "Interface IDs are required to be 64 bits
long" is blocking consensus on this draft, and it is difficult to see
the draft progressing with this in place.

For static IP address configuration, there no compelling reason to
specify any mask length restriction. If someone wants to configure an
arbitrary netmask on their network, then let them. If it breaks
something, they will learn not to do it again. This is a completely
self-policing issue and requires no input from the ietf.

Nick

[Brian E Carpenter]

On 11/07/2017 05:53, Nick Hilliard wrote:
> David Farmer wrote:
>> Or, how broad of an exception should we make?
>
> /0 to /128 would work for me.
>
> More seriously, the sentence "Interface IDs are required to be 64 bits
> long" is blocking consensus on this draft, and it is difficult to see
> the draft progressing with this in place.

Agreed. On the other hand, maybe rough consensus could be achieved
with s/required/recommended/, even if some objections remain.
The IETF does not require consensus, only rough consensus.

Neither of our WG Chairs is neutral on this issue; one is the
document editor, the other has a clear opinion, to which he is
completely entitled. Personally, I think the AD could step
in to judge consensus.

(Not to say that David Farmer's text is wrong, but Nick is
correct about the blocking issue.)

Brian

> For static IP address configuration, there no compelling reason to
> specify any mask length restriction. If someone wants to configure an
> arbitrary netmask on their network, then let them. If it breaks
> something, they will learn not to do it again. This is a completely
> self-policing issue and requires no input from the ietf.
>
> Nick
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ***@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> .
>

[Manfredi, Albert E]

-----Original Message-----
From: ipv6 [mailto:ipv6-***@ietf.org] On Behalf Of Brian E Carpenter

> Agreed. On the other hand, maybe rough consensus could be
> achieved with s/required/recommended/, even if some objections
> remain.

The problem I have is mainly that in the ebb and flow of these continuing discussions, one sees the "IIDs must be 64 bits wide" creeping back in, again and again. Where instead, the rough consensus seems to have become, must be 64-bits wide unless the addresses are statically configured or are provided by DHCPv6. In the latter cases, 64-bit IIDs might still be "recommended," but in fact, the on-link prefix length can be from zero to 128 bits, and the IID must therefore be 128 - prefix length.

Why not just state those two exceptions outright? Citing RFCs that mandated 64-bit IIDs doesn't hold much weight, if the rationale for doing so has been deprecated. Or they may be cited, but with that proviso. Yes, LLAs and ULAs still require 64-bit IIDs, as does SLAAC (to try to thwart a "race to the bottom").

I too was impressed with the thoroughness of David Farmer's thesis, but as far as I can tell, it doesn't change the above.

Bert

[David Farmer]

On Mon, Jul 10, 2017 at 7:21 PM, Manfredi, Albert E <
***@boeing.com> wrote:

> -----Original Message-----
> From: ipv6 [mailto:ipv6-***@ietf.org] On Behalf Of Brian E Carpenter
>
> > Agreed. On the other hand, maybe rough consensus could be
> > achieved with s/required/recommended/, even if some objections
> > remain.
>
> The problem I have is mainly that in the ebb and flow of these continuing
> discussions, one sees the "IIDs must be 64 bits wide" creeping back in,
> again and again. Where instead, the rough consensus seems to have become,
> must be 64-bits wide unless the addresses are statically configured or are
> provided by DHCPv6. In the latter cases, 64-bit IIDs might still be
> "recommended," but in fact, the on-link prefix length can be from zero to
> 128 bits, and the IID must therefore be 128 - prefix length.
>
> Why not just state those two exceptions outright? Citing RFCs that
> mandated 64-bit IIDs doesn't hold much weight, if the rationale for doing
> so has been deprecated. Or they may be cited, but with that proviso. Yes,
> LLAs and ULAs still require 64-bit IIDs, as does SLAAC (to try to thwart a
> "race to the bottom").
>
> I too was impressed with the thoroughness of David Farmer's thesis, but as
> far as I can tell, it doesn't change the above.
>

IPv6 as currently defined does actually require IIDs to be 64 bits, if this
wasn't the case then you could use subnets of any length without any
special requirements or considerations. RFC6164 is quite clear that there
are /127 prefixes that should not be used and there are other requirements
like disabling Subnet-Router anycast. However, as IPv6 unicast routing is
based on on-link prefixes of any length, up to 128 bits, limited IPv6
functionality can be provided using any length IID. In the case of
point-to-point links, the limitations are not a big deal, however it would
be a stretch to that the limitations are not an issue is all cases.

So, how about something like this;

For the full functioning of all IPv6 capabilities, when assigning unicast
addresses, except those that start with the binary value 000, Interface
Identifiers are required to be 64 bits long. However, as IPv6 unicast
routing and on-link determination are separate from address assignment and
will operate with Interface Identifiers of any length. It is therefore
possible, with several limitations, to use Interface Identifiers of other
lengths in limited scenarios, these include; 128 bit prefixes, such as for
router loopback addresses, point-to-point router-links [RFC6164], and links
where all node are manually configured.

--
===============================================
David Farmer Email:***@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: [phone] <(612)%20626-0815>
Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952>
===============================================

[David Farmer]

On Mon, Jul 10, 2017 at 11:59 PM, David Farmer <***@umn.edu> wrote:

>
>
> On Mon, Jul 10, 2017 at 7:21 PM, Manfredi, Albert E <
> ***@boeing.com> wrote:
>
>> -----Original Message-----
>> From: ipv6 [mailto:ipv6-***@ietf.org] On Behalf Of Brian E Carpenter
>>
>> > Agreed. On the other hand, maybe rough consensus could be
>> > achieved with s/required/recommended/, even if some objections
>> > remain.
>>
>> The problem I have is mainly that in the ebb and flow of these continuing
>> discussions, one sees the "IIDs must be 64 bits wide" creeping back in,
>> again and again. Where instead, the rough consensus seems to have become,
>> must be 64-bits wide unless the addresses are statically configured or are
>> provided by DHCPv6. In the latter cases, 64-bit IIDs might still be
>> "recommended," but in fact, the on-link prefix length can be from zero to
>> 128 bits, and the IID must therefore be 128 - prefix length.
>>
>> Why not just state those two exceptions outright? Citing RFCs that
>> mandated 64-bit IIDs doesn't hold much weight, if the rationale for doing
>> so has been deprecated. Or they may be cited, but with that proviso. Yes,
>> LLAs and ULAs still require 64-bit IIDs, as does SLAAC (to try to thwart a
>> "race to the bottom").
>>
>> I too was impressed with the thoroughness of David Farmer's thesis, but
>> as far as I can tell, it doesn't change the above.
>>
>
> IPv6 as currently defined does actually require IIDs to be 64 bits, if
> this wasn't the case then you could use subnets of any length without any
> special requirements or considerations. RFC6164 is quite clear that
> there are /127 prefixes that should not be used and there are other
> requirements like disabling Subnet-Router anycast. However, as IPv6
> unicast routing is based on on-link prefixes of any length, up to 128 bits,
> limited IPv6 functionality can be provided using any length IID. In the
> case of point-to-point links, the limitations are not a big deal, however
> it would be a stretch to that the limitations are not an issue is all
> cases.
>
> So, how about something like this;
>
> For the full functioning of all IPv6 capabilities, when assigning unicast
> addresses, except those that start with the binary value 000, Interface
> Identifiers are required to be 64 bits long. However, as IPv6 unicast
> routing and on-link determination are separate from address assignment and
> will operate with Interface Identifiers of any length. It is therefore
> possible, with several limitations, to use Interface Identifiers of other
> lengths in limited scenarios, these include; 128 bit prefixes, such as for
> router loopback addresses, point-to-point router-links [RFC6164], and links
> where all node are manually configured.
>

Oops, forgot something;

For the full functioning of all IPv6 capabilities, when assigning unicast
addresses, except those that start with the binary value 000, Interface
Identifiers are required to be 64 bits long. The rationale for using 64 bit
Interface Identifiers can be found in [RFC7421]. However, as IPv6 unicast
routing and on-link determination are separate from address assignment and
will operate with Interface Identifiers of any length. It is therefore
possible, with several limitations, to use Interface Identifiers of other
lengths in limited scenarios, these include; 128 bit prefixes, such as for
router loopback addresses, point-to-point router-links [RFC6164], and links
where all node are manually configured.


--
===============================================
David Farmer Email:***@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: [phone]
Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================

[Manfredi, Albert E]

From: David Farmer [mailto:***@umn.edu]

> IPv6 as currently defined does actually require IIDs to be 64 bits,
> if this wasn't the case then you could use subnets of any length
> without any special requirements or considerations.

And in general, you can. I think this is a stumbling block. There are examples where 64-bit IIDs are still required, and there are examples where they were required for reasons that no longer apply. But as of now, if you use static addresses, or similarly DHCPv6, you're not limited. Everything works fine with shorter IIDs. If you use SLAAC, you are limited to 64-bit IIDs, but that limitation is self-imposed, to try to keep other-than-64-bit-IIDs from becoming too easy to configure. In principle, it would be easy enough to remove that 64-bit limitation from SLAAC.

I'm opposed to continue to imply that 64-bit IIDs are "required," other than in cases like SLAAC, ULAs, LLAs. That word "required" is what causes the pushback.

Bert

[Mark Smith]

On 12 Jul. 2017 03:21, "Manfredi, Albert E" <***@boeing.com>
wrote:

From: David Farmer [mailto:***@umn.edu]

> IPv6 as currently defined does actually require IIDs to be 64 bits,
> if this wasn't the case then you could use subnets of any length
> without any special requirements or considerations.

And in general, you can. I think this is a stumbling block. There are
examples where 64-bit IIDs are still required, and there are examples where
they were required for reasons that no longer apply. But as of now, if you
use static addresses, or similarly DHCPv6, you're not limited. Everything
works fine with shorter IIDs.


This is not recognising that there are more than operational or functional
properties of addresses. They have privacy and security properties too.

As an example, the stateful DHCPv6 server in OpenWRT currently compromises
those security and privacy properties as it is enabled by default, as the
range of IIDs it uses is the same size as the DHCPv4 server's address range
e.g. 100 addresses. (OpenWRT supports both SLAAC and Stateful DHCPv6 by
default, my hosts that support both had great private/secure addresses
through SLAAC and terrible ones through DHCPv6)

In IPv4, this is less of a concern, because NAT provided a layer of
security and privacy to individual hosts' addresses, in particular to
residential users. If we advocate for removing NAT from IPv6, or more
accurately advocate end-to-end addressing, we need to provide alternate
methods to restore the privacy and security provided by NAT.

Those methods should also not be reliant on devices or functions in the
network, because the hosts that need them the most are also very portable
(i.e., smartphones and laptops), and are easily and commonly attached to
untrustable public networks.


If

you use SLAAC, you are limited to 64-bit IIDs, but that limitation is
self-imposed, to try to keep other-than-64-bit-IIDs from becoming too easy
to configure. In principle, it would be easy enough to remove that 64-bit
limitation from SLAAC.

I'm opposed to continue to imply that 64-bit IIDs are "required," other
than in cases like SLAAC, ULAs, LLAs. That word "required" is what causes
the pushback.

Bert

[Brian E Carpenter]

On 12/07/2017 11:54, Mark Smith wrote:
>> On 12 Jul. 2017 03:21, "Manfredi, Albert E" <***@boeing.com>
>> wrote:
>>
>> From: David Farmer [mailto:***@umn.edu]
>>
>>> IPv6 as currently defined does actually require IIDs to be 64 bits,
>>> if this wasn't the case then you could use subnets of any length
>>> without any special requirements or considerations.
>>
>> And in general, you can. I think this is a stumbling block. There are
>> examples where 64-bit IIDs are still required, and there are examples where
>> they were required for reasons that no longer apply. But as of now, if you
>> use static addresses, or similarly DHCPv6, you're not limited. Everything
>> works fine with shorter IIDs.
>>
>
> This is not recognising that there are more than operational or functional
> properties of addresses. They have privacy and security properties too.

Very specifically, it would be irresponsible not to require pseudo-random
IIDs of at least N bits for automatically assigned addresses. RFC7217
doesn't define N, but I assume it would be at least 40 and probably more.

The advantage of requiring or recommending 64 bits is that it avoids the
debate about N. I prefer 'recommend' because it avoids enumerating all
possible exceptions. We've seen how hard it is to wordsmith the exceptions.

Brian

> As an example, the stateful DHCPv6 server in OpenWRT currently compromises
> those security and privacy properties as it is enabled by default, as the
> range of IIDs it uses is the same size as the DHCPv4 server's address range
> e.g. 100 addresses. (OpenWRT supports both SLAAC and Stateful DHCPv6 by
> default, my hosts that support both had great private/secure addresses
> through SLAAC and terrible ones through DHCPv6)
>
> In IPv4, this is less of a concern, because NAT provided a layer of
> security and privacy to individual hosts' addresses, in particular to
> residential users. If we advocate for removing NAT from IPv6, or more
> accurately advocate end-to-end addressing, we need to provide alternate
> methods to restore the privacy and security provided by NAT.
>
> Those methods should also not be reliant on devices or functions in the
> network, because the hosts that need them the most are also very portable
> (i.e., smartphones and laptops), and are easily and commonly attached to
> untrustable public networks.
>
>
> If
>
> you use SLAAC, you are limited to 64-bit IIDs, but that limitation is
> self-imposed, to try to keep other-than-64-bit-IIDs from becoming too easy
> to configure. In principle, it would be easy enough to remove that 64-bit
> limitation from SLAAC.
>
> I'm opposed to continue to imply that 64-bit IIDs are "required," other
> than in cases like SLAAC, ULAs, LLAs. That word "required" is what causes
> the pushback.
>
> Bert
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ***@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ***@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

[Manfredi, Albert E]

-----Original Message-----
From: Brian E Carpenter [mailto:***@gmail.com]

> Very specifically, it would be irresponsible not to require
> pseudo-random IIDs of at least N bits for automatically assigned
> addresses. RFC7217 doesn't define N, but I assume it would be at
> least 40 and probably more.

Exactly. This is one example that should not mandate 64, but rather whatever is enough for all the considerations that have to be made. For collisions or security, 48 or 40 bits is probably plenty, depending also on the number of hosts expected in a subnet prefix. Within a homenet, I'd much rather depend on a firewall than an overabundance of IID bits, for instance.

> The advantage of requiring or recommending 64 bits is that it
> avoids the debate about N.

But it penalizes applications that would benefit from more flexibility. Much of the problem comes from our inability to even define what a "site" might be, to which a /48 might theoretically be assigned (if we even believe that's a realistic expectation anymore?). So, not knowing what constitutes "site," and not believing that all sites will get anything better than a /64, I think we need to avoid having device makers create hard 64-bit IID boundaries. It would be unfortunate if every thermometer and thermostat were required to have a 64-bit IID. *Or* were built that way, because someone read that 64-bit IIDs are "required."

Bert

[Brian E Carpenter]

On 12/07/2017 15:18, Manfredi, Albert E wrote:
> -----Original Message-----
> From: Brian E Carpenter [mailto:***@gmail.com]
>
>> Very specifically, it would be irresponsible not to require
>> pseudo-random IIDs of at least N bits for automatically assigned
>> addresses. RFC7217 doesn't define N, but I assume it would be at
>> least 40 and probably more.
>
> Exactly. This is one example that should not mandate 64, but rather whatever is enough for all the considerations that have to be made. For collisions or security, 48 or 40 bits is probably plenty, depending also on the number of hosts expected in a subnet prefix. Within a homenet, I'd much rather depend on a firewall than an overabundance of IID bits, for instance.
>
>> The advantage of requiring or recommending 64 bits is that it
>> avoids the debate about N.
>
> But it penalizes applications that would benefit from more flexibility. Much of the problem comes from our inability to even define what a "site" might be, to which a /48 might theoretically be assigned (if we even believe that's a realistic expectation anymore?). So, not knowing what constitutes "site," and not believing that all sites will get anything better than a /64, I think we need to avoid having device makers create hard 64-bit IID boundaries. It would be unfortunate if every thermometer and thermostat were required to have a 64-bit IID. *Or* were built that way, because someone read that 64-bit IIDs are "required."

I'm not convinced. I'm arguing for flexibility so that we don't look
stupid in 50 years time, but 15 trillion /48s is an awful lot of /48s,
even for the Internet of Things. I don't really have a problem with
64 bit IIDs in light switches.

Brian

[Mark Smith]

On 12 July 2017 at 13:18, Manfredi, Albert E
<***@boeing.com> wrote:
> -----Original Message-----
> From: Brian E Carpenter [mailto:***@gmail.com]
>
>> Very specifically, it would be irresponsible not to require
>> pseudo-random IIDs of at least N bits for automatically assigned
>> addresses. RFC7217 doesn't define N, but I assume it would be at
>> least 40 and probably more.
>
> Exactly. This is one example that should not mandate 64, but rather whatever is enough for all the considerations that have to be made. For collisions or security, 48 or 40 bits is probably plenty, depending also on the number of hosts expected in a subnet prefix. Within a homenet, I'd much rather depend on a firewall than an overabundance of IID bits, for instance.
>

How many are enough, and do you expect non-technical end-users to make
good decisions about how many bits they need for their privacy and
security?

RFC5505, "Principles of Internet Host Configuration"

"2.1. Minimize Configuration

Anything that can be configured can be misconfigured."

>> The advantage of requiring or recommending 64 bits is that it
>> avoids the debate about N.
>
> But it penalizes applications that would benefit from more flexibility. Much of the problem comes from our inability to even define what a "site" might be, to which a /48 might theoretically be assigned (if we even believe that's a realistic expectation anymore?).
>So, not knowing what constitutes "site," and not believing that all sites will get anything better than a /64,

/64 per-site looks to be proving to be the exception rather than the
rule. I've been casually observing what ISPs give out, because having
worked at residential ISPs (and one who provided the first production
IPv6 on residential broadband in Australia back in 2011), they've
tended to make static IPv4 addresses and routed subnets a premium or
business only product option with a corresponding price premium. I
expected that becoming a standard IPv6 feature may be resisted
significantly.

Most are giving out /56s. I know of one that is now giving out /60s,
and they originally gave out a single /64. I know of one that is
giving out a single /64 on their residential plans, and in the forum
that is being complained about, people are pointing out that other
ISPs are giving out /56s.

Here in Australia it is usual for our incumbent Telco to charge the
most, sometimes for the least, yet they too are giving out /56s
standard on residential plans.

In a market where there is choice, being miserly with assigned IPv6
address space won't persist for long if it causes trouble for
customers - the time and staff cost of dealing with their complaint
will outweigh any costs of giving them plenty of address space in the
first place.

> I think we need to avoid having device makers create hard 64-bit IID boundaries. It would be unfortunate if every thermometer and thermostat were required to have a 64-bit IID.


What are the specific drawbacks or advantages of thermometer and
thermostats not having 64 bit IIDs? I can't think of any. It doesn't
reduce the code in them, nor can I see how it somehow reduces the
number of packets they need to send, and I don't see how if they were
battery operated it would make a beneficial difference to their
battery life.

Being hidden in a 64 bit IID address space does make them a less
likely target for a DoS attack, assuming they've somehow been made
reachable by somebody who would benefit from them being DoS'd.

What are some applications that would benefit from more flexibility?
Are you talking about applications where the flexibility would be an
additional benefit to the application, or ones where the flexibility
would be required to work around not having a 64 bit IID available?


>*Or* were built that way, because someone read that 64-bit IIDs are "required."
>

64 bit IIDs have been written as required since July 1998 in RFC2373.
In some countries this requirement can drive, vote in elections and
drink alcohol.


"In a number of the format prefixes (see section 2.4) Interface IDs
are required to be 64 bits long and to be constructed in IEEE EUI-64
format [EUI64]."

...

" The details of forming interface identifiers are defined in the
appropriate "IPv6 over <link>" specification such as "IPv6 over
Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc."



Regards,
Mark.

[David Farmer]

On Wed, Jul 12, 2017 at 2:47 AM, Mark Smith <***@gmail.com> wrote:

>
> /64 per-site looks to be proving to be the exception rather than the
> rule. I've been casually observing what ISPs give out, because having
> worked at residential ISPs (and one who provided the first production
> IPv6 on residential broadband in Australia back in 2011), they've
> tended to make static IPv4 addresses and routed subnets a premium or
> business only product option with a corresponding price premium. I
> expected that becoming a standard IPv6 feature may be resisted
> significantly.
>
> Most are giving out /56s. I know of one that is now giving out /60s,
> and they originally gave out a single /64. I know of one that is
> giving out a single /64 on their residential plans, and in the forum
> that is being complained about, people are pointing out that other
> ISPs are giving out /56s.
>
> Here in Australia it is usual for our incumbent Telco to charge the
> most, sometimes for the least, yet they too are giving out /56s
> standard on residential plans.
>
> In a market where there is choice, being miserly with assigned IPv6
> address space won't persist for long if it causes trouble for
> customers - the time and staff cost of dealing with their complaint
> will outweigh any costs of giving them plenty of address space in the
> first place.
>

All I can say is hope so, but from my perspective I'm not seeing it, I'm
seeing /64s per customer.

Related to this I've said several times that section 2.4.4 of RFC4291bis
needs work. If we are going to keep a clear 64 bit IID requirement, we
need to be equally resolute that ISPs assigning only a /64 is wrong. I'd
like to see some of you that are resolute that we keep the 64 bit IID
requirement commenting about section 2.4.4's issues.

Minimally, for section 2.4.4, I'd like to see a statement that m>1 and a
more direct pointer to RFC6177.

Thanks.

--
===============================================
David Farmer Email:***@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: [phone]
Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================

[Manfredi, Albert E]

-----Original Message-----
From: Mark Smith [mailto:***@gmail.com]

> What are the specific drawbacks or advantages of thermometer
> and thermostats not having 64 bit IIDs?

I'm fairly certain that if the IETF could somehow guarantee that every "site" (however that's defined) were allocated a /48, there wouldn't be so much of an issue. This is another one of those arguments that keeps cycling, though. The pro-64-bit boundary camp says that there are plenty of /48s to go around. Fine and good, but the other camp says, how come /48s are not being handed out, then? So it's a question of theory vs reality.

The drawbacks are generic, but let's take HVAC. The system gets upgraded, from a relatively old school design, with a few interfaces to the platform network, and much hard wiring behind these, to several hundred networked interfaces within the HVAC subsystem.

With a hard 64-bit boundary, I'm constrained to creating a flat address space for the upgraded HVAC system, with all these little gizmos hanging off the platform network. That can work, because 64-bit IIDs allow for lots of devices. Alternatively, I can create new /60s or /62s, for this upgraded HVAC system, assuming I have enough prefix space to work with!

But with IID flexibility, I can partition the upgraded HVAC system into its own subnets, behind the previous platform network interfaces to HVAC, with no trouble at all, even if the entire platform was only allocated, say, a /56, or for that matter, even a /64.

Of course, the other option is to expand using ULAs, but then, that's "so IPv4."

Bert

[DY Kim]

It seems to me that people have to beat rfc7421 first before stopping rfc4291bis from going forwards:

rfc4291bis: "The rationale for using 64 bit Interface Identifiers can be found in [RFC7421].”

—-
DY

[Brian E Carpenter]

On 13/07/2017 06:32, Manfredi, Albert E wrote:
...
> Of course, the other option is to expand using ULAs, but then, that's "so IPv4."

Not. ULA doesn't imply NAT. It just implies private addresses.
I think keeping the addresses of my light switches private and not
globally reachable is a wonderful idea. My lighting controller
might be accessible via a global address, and would hopefully have
much better security than the individual lightswitches.

Brian

[Mark Smith]

On 13 July 2017 at 11:42, Brian E Carpenter <***@gmail.com> wrote:
> On 13/07/2017 06:32, Manfredi, Albert E wrote:
> ...
>> Of course, the other option is to expand using ULAs, but then, that's "so IPv4."
>
> Not. ULA doesn't imply NAT. It just implies private addresses.
> I think keeping the addresses of my light switches private and not
> globally reachable is a wonderful idea. My lighting controller
> might be accessible via a global address, and would hopefully have
> much better security than the individual lightswitches.
>

Agree. ULAs is not "so IPv4".

I know of at least two AMI Smartmeter networks with well over 300K
meters attached that are using IPv6 and ULAs. They don't need global
reachability to or from the Internet, so they don't need GUA addresses
(and they're certainly not getting Internet reachability via NAT66
either).

Regards,
Mark.

[Manfredi, Albert E]

-----Original Message-----
From: ipv6 [mailto:ipv6-***@ietf.org] On Behalf Of Brian E Carpenter

>> Of course, the other option is to expand using ULAs, but then, that's
>> "so IPv4."
>
> Not. ULA doesn't imply NAT.

I never mentioned NAT, Brian. "So IPv4" was meant to imply use of RFC 1918. In fact, I can expand a public IPv4 or IPv6 address space, using private IP addresses or ULAs, with the same advantages and limitations. I can route these inside my network, overcoming the limitations that have a way of creeping up over time.

The problem is that over time, way more IP addresses become necessary, not just a few more. It's because so many more systems adopt IP, and become so much smarter than they used to be. So you need flexibility to expand, not just in number of connected devices, but also in the architecture of the network.

Bert

[Brian E Carpenter]

On 13/07/2017 13:51, Manfredi, Albert E wrote:
> -----Original Message-----
> From: ipv6 [mailto:ipv6-***@ietf.org] On Behalf Of Brian E Carpenter
>
>>> Of course, the other option is to expand using ULAs, but then, that's
>>> "so IPv4."
>>
>> Not. ULA doesn't imply NAT.
>
> I never mentioned NAT, Brian. "So IPv4" was meant to imply use of RFC 1918. In fact, I can expand a public IPv4 or IPv6 address space, using private IP addresses or ULAs, with the same advantages and limitations. I can route these inside my network, overcoming the limitations that have a way of creeping up over time.
>
> The problem is that over time, way more IP addresses become necessary, not just a few more. It's because so many more systems adopt IP, and become so much smarter than they used to be. So you need flexibility to expand, not just in number of connected devices, but also in the architecture of the network.

Sure. Which is why we have always advocated /48 to end users.

Truth be told, I liked RFC3177 a lot more than RFC6177. But 6177 is more realistic.

Brian

[Manfredi, Albert E]

-----Original Message-----
From: pch-***@u-1.phicoh.com [mailto:pch-***@u-1.phicoh.com] On Behalf Of Philip Homburg

>> The problem is that over time, way more IP addresses become necessary,
>> not just a few more. It's because so many more systems adopt IP, and
>> become so much smarter than they used to be. So you need flexibility
>> to expand, not just in number of connected devices, but also in the
>> architecture of the network.
>
> Using pseudo-random IIDs comes with the risk of collisions. So you have
> to waste lots of bits to get that risk down to an acceptable level.

With DHCP, or with static configuration of hosts, you don't have any risk of collisions. And the risk of collisions with fewer than 64 bits is not necessarily a problem. The risk of collisions with 48 bits should be acceptable too. However, if we continue the self-imposed limit of 64 bit IIDs for SLAAC, that becomes a non-problem.

I'm belaboring here, but if, at the same time, "sites" (again, however that is defined) are assigned /64s, or /56s, and we continue to insist that IIDs must be 64 bits, then the plain result is that we're back to where we were with IPv4. Expansion becomes a problem. Either you go back and get more address space, or you use IPv4-like techniques. And to avoid the conclusions people arrived at last time, I'm talking about using ULAs. Just like it was with private addresses in IPv4.

The rationale people give that /48s should be plentiful may be fine. Problem is, it becomes irrelevant, if /48s are not handed out. The IETF has no police powers here, so that rationale is not reflecting reality.

> However, since the mid 90s we have a protocol for dense allocation of
> addresses. Where in the 64-bit IID space you can fit an entire universe.

In a flat universe, maybe. No one is disputing that 64 bit IIDs allow for many hosts in a single subnet prefix. But we also discovered in the 1980s and 1990s how bad it is to create gymongous IP subnets.

Bert

[Mark Smith]

On 15 July 2017 at 23:51, Philip Homburg <pch-ipv6-ietf-***@u-1.phicoh.com> wrote:
>> > However, since the mid 90s we have a protocol for dense allocation of
>> > addresses. Where in the 64-bit IID space you can fit an entire universe.
>>
>> In a flat universe, maybe. No one is disputing that 64 bit IIDs
>> allow for many hosts in a single subnet prefix. But we also discovered
>> in the 1980s and 1990s how bad it is to create gymongous IP subnets.
>
> Just in case you missed it, I'm advocating that 64 bit IIDs only apply to
> SLAAC and not to DHCPv6 IA_NA.
>
> So using DHCP, a /64 prefix can be subdivided exactly as you want. You can
> for example hand out a /96 prefix using IA_PD to every link and then
> per link you still have more than enough addresses.
>

More than enough addresses for what specifically? Privacy and security
get lost with /96 prefixes.

Trying to accommodate /64 per multi-subnet site is trying to
accommodate irrationality. When a the smallest GUA allocation from an
RIR provides 4 billion /64s and a ULA provides 65 536 /64s (and of
course you can generate more of your own ULA /48s if that is not
enough), being miserly with IPv6 /64s is irrational.

We can go down that path, and we'll end up trying to engineer around
greater and greater irrationality - "If you make something idiot
proof, someone will just make a better idiot." We know the likely
final end-result of accommodating >/64s would be a /128 per site and
IPv6 NAPT, because irrational people will treat IPv6 addresses as
though they're gold rather than lead, because they can.


> Note that I believe Lorenzo's argument is valid. The reason we can expect a
> /64 to be there is that SLAAC requires a /64. If we relax that requirement
> then soon we will see longer prefixes pop up and are back to square one.
>
> For DHCP I don't care. For SLAAC I just don't want the collision risk. So
> keep SLAAC at 64 and use DHCP for anything else.
>

Collision risk also exists in DHCPv6. There is no requirement that a
single prefix is exclusively using stateful DHCPv6 or exclusively
using SLAAC. OpenWRT by default provides addresses via SLAAC and
stateful DHCPv6 from within the same prefix.

rfc3315bis is adding an a MUST DAD check because of this.

Worse, OpenWRT uses the same IPv4 address range size for IPv6 stateful
DHCPv6. Your host can have SLAAC generated 64 bit privacy addresses
and 64 bit RFC7217 stable addresses, and then if it too supports
stateful DHCPv6, then it's stateful DHCPv6 addresses will be from an
address space smaller than 8 bits, from within a GUA prefix.

Regards,
Mark.




> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ***@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

[Brian E Carpenter]

On 13/07/2017 22:33, Philip Homburg wrote:
>> The problem is that over time, way more IP addresses become necessary, not just a
>> few more. It's because so many more systems adopt IP, and become so much smarter
>> than they used to be. So you need flexibility to expand, not just in number of c
>> onnected devices, but also in the architecture of the network.
>
> Using pseudo-random IIDs comes with the risk of collisions. So you have to waste
> lots of bits to get that risk down to an acceptable level.

This is backwards. The goals of pseudo-random IIDs are to reduce the
probability that scanning attacks find hosts, and to reduce the risk
of IIDs being used to breach privacy.

If these goals are met, the collision probability will in any case
be low, so DAD failure will be exceedingly rare.

> It is a really bad
> trade-off if your ability to expand the network comes at the price of increased
> risk of collision.

That seems completely theoretical for any IID length that would be acceptable
under the above goals. If there's a significant risk of collision, the IID
is too short to protect against scanning attacks or address-based surveillance,
so is unacceptable anyway.

Brian

[Brian E Carpenter]

On 16/07/2017 01:39, Philip Homburg wrote:
>> This is backwards. The goals of pseudo-random IIDs are to reduce the
>> probability that scanning attacks find hosts, and to reduce the risk
>> of IIDs being used to breach privacy.
>>
>> If these goals are met, the collision probability will in any case
>> be low, so DAD failure will be exceedingly rare.
>
> I completely disagree. A collision is fatal. We are nowhere near transparently
> handling all collisions. At best we can hope that DAD can make one node
> continue unaffected.

I'm confused.

Firstly, do we have any experimental evidence that collisions
are a real operational problem? (Obviously, MAC address collisions are
disastrous at layer 2 anyway, so although IPv6+(Modified EUI-64) needs to
detect them, they are irrelevant to the current discussion.)

Secondly, if a collision does occur with IPv6+(pseudo-random IID),
recovery is obvious: after DAD failure, generate a new pseudo-random
IID and try again. This is perfectly compatible with RFC4862 section 5.5
and is specfied in RFC7217 for stable IIDs and in RFC4941 for privacy
addresses.

Brian

>
> In contrast, people have been scanning my IPv4 ranges for the past 20 years
> or so. That may be annoying. That may amplify attacks opportunities. But
> in it self it is not fatal.
>
>
> .
>

[Pascal Thubert (pthubert)]

Hello Brian:

I'd say that DAD detecting a duplication is not a failure; just doing its job right.

The DAD failure that hurts is DAD false negative like can be easily obtained on wireless because the reliability of the multicast is largely different from that of wire.

Are we ready to say that addresses that are generated with enough randomness in them do not need DAD?

Pascal

> Le 15 juil. 2017 à 23:01, Brian E Carpenter <***@gmail.com> a écrit :
>
> On 16/07/2017 01:39, Philip Homburg wrote:
>>> This is backwards. The goals of pseudo-random IIDs are to reduce the
>>> probability that scanning attacks find hosts, and to reduce the risk
>>> of IIDs being used to breach privacy.
>>>
>>> If these goals are met, the collision probability will in any case
>>> be low, so DAD failure will be exceedingly rare.
>>
>> I completely disagree. A collision is fatal. We are nowhere near transparently
>> handling all collisions. At best we can hope that DAD can make one node
>> continue unaffected.
>
> I'm confused.
>
> Firstly, do we have any experimental evidence that collisions
> are a real operational problem? (Obviously, MAC address collisions are
> disastrous at layer 2 anyway, so although IPv6+(Modified EUI-64) needs to
> detect them, they are irrelevant to the current discussion.)
>
> Secondly, if a collision does occur with IPv6+(pseudo-random IID),
> recovery is obvious: after DAD failure, generate a new pseudo-random
> IID and try again. This is perfectly compatible with RFC4862 section 5.5
> and is specfied in RFC7217 for stable IIDs and in RFC4941 for privacy
> addresses.
>
> Brian
>
>>
>> In contrast, people have been scanning my IPv4 ranges for the past 20 years
>> or so. That may be annoying. That may amplify attacks opportunities. But
>> in it self it is not fatal.
>>
>>
>> .
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ***@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

[Mark Smith]

On 16 July 2017 at 16:41, Pascal Thubert (pthubert) <***@cisco.com> wrote:
> Hello Brian:
>
> I'd say that DAD detecting a duplication is not a failure; just doing its job right.
>
> The DAD failure that hurts is DAD false negative like can be easily obtained on wireless because the reliability of the multicast is largely different from that of wire.
>
> Are we ready to say that addresses that are generated with enough randomness in them do not need DAD?
>

I looked up RFC4862 to find out how many DAD attempts there were,
because I'd assumed 3 to 4, and if so, then if that many attempts
failed, I'd say the link is well beyond its capacity. Something would
need to be done to remedy a link capacity problem in that case.

I was surprised to find, as Ole mentioned, the number of attempts was
only 1 rather than 3 or 4.

One thing it does say about that value is:

Default: 1, but may be overridden by a link-type specific value in
the document that covers issues related to the transmission of IP
over a particular link type (e.g., [RFC2464]).

Although Wifi is emulating Ethernet at the IPv6 interface layer, it
doesn't have the same multicast characteristics, so perhaps there
should be an IPv6 over Wifi RFC that specifies IPv6's parameters to
suit.




> Pascal
>
>> Le 15 juil. 2017 à 23:01, Brian E Carpenter <***@gmail.com> a écrit :
>>
>> On 16/07/2017 01:39, Philip Homburg wrote:
>>>> This is backwards. The goals of pseudo-random IIDs are to reduce the
>>>> probability that scanning attacks find hosts, and to reduce the risk
>>>> of IIDs being used to breach privacy.
>>>>
>>>> If these goals are met, the collision probability will in any case
>>>> be low, so DAD failure will be exceedingly rare.
>>>
>>> I completely disagree. A collision is fatal. We are nowhere near transparently
>>> handling all collisions. At best we can hope that DAD can make one node
>>> continue unaffected.
>>
>> I'm confused.
>>
>> Firstly, do we have any experimental evidence that collisions
>> are a real operational problem? (Obviously, MAC address collisions are
>> disastrous at layer 2 anyway, so although IPv6+(Modified EUI-64) needs to
>> detect them, they are irrelevant to the current discussion.)
>>
>> Secondly, if a collision does occur with IPv6+(pseudo-random IID),
>> recovery is obvious: after DAD failure, generate a new pseudo-random
>> IID and try again. This is perfectly compatible with RFC4862 section 5.5
>> and is specfied in RFC7217 for stable IIDs and in RFC4941 for privacy
>> addresses.
>>
>> Brian
>>
>>>
>>> In contrast, people have been scanning my IPv4 ranges for the past 20 years
>>> or so. That may be annoying. That may amplify attacks opportunities. But
>>> in it self it is not fatal.
>>>
>>>
>>> .
>>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ***@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ***@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

[Brian E Carpenter]

On 16/07/2017 19:58, Mark Smith wrote:
> On 16 July 2017 at 16:41, Pascal Thubert (pthubert) <***@cisco.com> wrote:
>> Hello Brian:
>>
>> I'd say that DAD detecting a duplication is not a failure; just doing its job right.
>>
>> The DAD failure that hurts is DAD false negative like can be easily obtained on wireless because the reliability of the multicast is largely different from that of wire.
>>
>> Are we ready to say that addresses that are generated with enough randomness in them do not need DAD?

I'm not, for 3 reasons:

1. An address collision is so fatal that we cannot leave it open as
even a remote possibility. It could be literally fatal in a safety-critical
application.

2. Even if we specify pseudo-random IDs, we know that some people will
nevertheless define them manually, which leads to a real risk of
collision due to human error. See 1.

3. A bad actor might create an intentional collision. See 1.

So, DAD needs to work.

>
> I looked up RFC4862 to find out how many DAD attempts there were,
> because I'd assumed 3 to 4, and if so, then if that many attempts
> failed, I'd say the link is well beyond its capacity. Something would
> need to be done to remedy a link capacity problem in that case.
>
> I was surprised to find, as Ole mentioned, the number of attempts was
> only 1 rather than 3 or 4.

I'm more than surprised. I think that's a bug and IMHO it should be fixed.

> One thing it does say about that value is:
>
> Default: 1, but may be overridden by a link-type specific value in
> the document that covers issues related to the transmission of IP
> over a particular link type (e.g., [RFC2464]).
>
> Although Wifi is emulating Ethernet at the IPv6 interface layer, it
> doesn't have the same multicast characteristics, so perhaps there
> should be an IPv6 over Wifi RFC that specifies IPv6's parameters to
> suit.

Pascal is correct about the intrinsic issues with relying on layer 2
multicast, but we are stuck with it for a while, so a fix seems
necessary.

Brian
>
>
>
>
>> Pascal
>>
>>> Le 15 juil. 2017 à 23:01, Brian E Carpenter <***@gmail.com> a écrit :
>>>
>>> On 16/07/2017 01:39, Philip Homburg wrote:
>>>>> This is backwards. The goals of pseudo-random IIDs are to reduce the
>>>>> probability that scanning attacks find hosts, and to reduce the risk
>>>>> of IIDs being used to breach privacy.
>>>>>
>>>>> If these goals are met, the collision probability will in any case
>>>>> be low, so DAD failure will be exceedingly rare.
>>>>
>>>> I completely disagree. A collision is fatal. We are nowhere near transparently
>>>> handling all collisions. At best we can hope that DAD can make one node
>>>> continue unaffected.
>>>
>>> I'm confused.
>>>
>>> Firstly, do we have any experimental evidence that collisions
>>> are a real operational problem? (Obviously, MAC address collisions are
>>> disastrous at layer 2 anyway, so although IPv6+(Modified EUI-64) needs to
>>> detect them, they are irrelevant to the current discussion.)
>>>
>>> Secondly, if a collision does occur with IPv6+(pseudo-random IID),
>>> recovery is obvious: after DAD failure, generate a new pseudo-random
>>> IID and try again. This is perfectly compatible with RFC4862 section 5.5
>>> and is specfied in RFC7217 for stable IIDs and in RFC4941 for privacy
>>> addresses.
>>>
>>> Brian
>>>
>>>>
>>>> In contrast, people have been scanning my IPv4 ranges for the past 20 years
>>>> or so. That may be annoying. That may amplify attacks opportunities. But
>>>> in it self it is not fatal.
>>>>
>>>>
>>>> .
>>>>
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ***@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ***@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>

[Ole Troan]

Brian,

DAD is not robust. Last time I tried on the IETF wireless network 1 time in 4 DAD failed to detect a duplicate.

Happy if anyone could do a more thorough experiment.

Cheers
Ole

> On 15 Jul 2017, at 23:01, Brian E Carpenter <***@gmail.com> wrote:
>
> On 16/07/2017 01:39, Philip Homburg wrote:
>>> This is backwards. The goals of pseudo-random IIDs are to reduce the
>>> probability that scanning attacks find hosts, and to reduce the risk
>>> of IIDs being used to breach privacy.
>>>
>>> If these goals are met, the collision probability will in any case
>>> be low, so DAD failure will be exceedingly rare.
>>
>> I completely disagree. A collision is fatal. We are nowhere near transparently
>> handling all collisions. At best we can hope that DAD can make one node
>> continue unaffected.
>
> I'm confused.
>
> Firstly, do we have any experimental evidence that collisions
> are a real operational problem? (Obviously, MAC address collisions are
> disastrous at layer 2 anyway, so although IPv6+(Modified EUI-64) needs to
> detect them, they are irrelevant to the current discussion.)
>
> Secondly, if a collision does occur with IPv6+(pseudo-random IID),
> recovery is obvious: after DAD failure, generate a new pseudo-random
> IID and try again. This is perfectly compatible with RFC4862 section 5.5
> and is specfied in RFC7217 for stable IIDs and in RFC4941 for privacy
> addresses.
>
> Brian
>
>>
>> In contrast, people have been scanning my IPv4 ranges for the past 20 years
>> or so. That may be annoying. That may amplify attacks opportunities. But
>> in it self it is not fatal.
>>
>>
>> .
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ***@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

[Nick Hilliard]

Ole Troan wrote:
> DAD is not robust. Last time I tried on the IETF wireless network 1
> time in 4 DAD failed to detect a duplicate.

was this an implementation problem or a protocol problem?

Nick

[Ole Troan]

Nick,

This a protocol problem. DAD is built with the assumption that physical links are reliable. 20% packet loss for multicast is common on wifi...

Cheers
Ole

> On 15 Jul 2017, at 23:34, Nick Hilliard <***@foobar.org> wrote:
>
> Ole Troan wrote:
>> DAD is not robust. Last time I tried on the IETF wireless network 1
>> time in 4 DAD failed to detect a duplicate.
>
> was this an implementation problem or a protocol problem?
>
> Nick

[Nick Hilliard]

Ole Troan wrote:
> This a protocol problem. DAD is built with the assumption that
> physical links are reliable. 20% packet loss for multicast is common
> on wifi...

most protocols will croak at 20% packet loss. If wifi cannot support
multicast properly, then this is an 802.11 problem rather than a problem
with DAD or any of the many other bits of ipv6 that depend on moderately
reliable multicast.

Nick

[Brian E Carpenter]

On 16/07/2017 10:22, Nick Hilliard wrote:
> Ole Troan wrote:
>> This a protocol problem. DAD is built with the assumption that
>> physical links are reliable. 20% packet loss for multicast is common
>> on wifi...
>
> most protocols will croak at 20% packet loss. If wifi cannot support
> multicast properly, then this is an 802.11 problem rather than a problem
> with DAD or any of the many other bits of ipv6 that depend on moderately
> reliable multicast.

I'm curious. If DAD has that problem, why doesn't Neighbor Discovery
have an equally bad problem?

BTW, Ole is correct. While testing the GRASP prototype at the last IETF,
we discovered a high loss rate for LL multicast on the network.
However, it wasn't primarily due to WiFi. It was due to intentional
multicast throttling in the switches:
https://mailarchive.ietf.org/arch/msg/anima/g4SUu-Bhkew-54hiJF1VPP8tfcQ

Brian

[David Farmer]

> On Jul 15, 2017, at 17:41, Brian E Carpenter <***@gmail.com> wrote:
>
>> On 16/07/2017 10:22, Nick Hilliard wrote:
>> Ole Troan wrote:
>>> This a protocol problem. DAD is built with the assumption that
>>> physical links are reliable. 20% packet loss for multicast is common
>>> on wifi...
>>
>> most protocols will croak at 20% packet loss. If wifi cannot support
>> multicast properly, then this is an 802.11 problem rather than a problem
>> with DAD or any of the many other bits of ipv6 that depend on moderately
>> reliable multicast.
>
> I'm curious. If DAD has that problem, why doesn't Neighbor Discovery
> have an equally bad problem?
>
> BTW, Ole is correct. While testing the GRASP prototype at the last IETF,
> we discovered a high loss rate for LL multicast on the network.
> However, it wasn't primarily due to WiFi. It was due to intentional
> multicast throttling in the switches:
> https://mailarchive.ietf.org/arch/msg/anima/g4SUu-Bhkew-54hiJF1VPP8tfcQ

Wifi APs, especially enterprise grade Wifi APs, frequently do arp and ND proxy, and they convert the responses from the proxy to unicast at the 802.11 layer. Sometimes they even only do unicast at the 802.11 layer and replicate all multicast into 802.11 unicasts. Frequently this is more efficient than multicast because of the differences between the basic rate encoding used for multicast packets vs the usually much higher density encoding used for unicast packets.

That usually keeps things working well enough.

[Brian E Carpenter]

On 16/07/2017 11:37, David Farmer wrote:
>
>> On Jul 15, 2017, at 17:41, Brian E Carpenter <***@gmail.com> wrote:
>>
>>> On 16/07/2017 10:22, Nick Hilliard wrote:
>>> Ole Troan wrote:
>>>> This a protocol problem. DAD is built with the assumption that
>>>> physical links are reliable. 20% packet loss for multicast is common
>>>> on wifi...
>>>
>>> most protocols will croak at 20% packet loss. If wifi cannot support
>>> multicast properly, then this is an 802.11 problem rather than a problem
>>> with DAD or any of the many other bits of ipv6 that depend on moderately
>>> reliable multicast.
>>
>> I'm curious. If DAD has that problem, why doesn't Neighbor Discovery
>> have an equally bad problem?
>>
>> BTW, Ole is correct. While testing the GRASP prototype at the last IETF,
>> we discovered a high loss rate for LL multicast on the network.
>> However, it wasn't primarily due to WiFi. It was due to intentional
>> multicast throttling in the switches:
>> https://mailarchive.ietf.org/arch/msg/anima/g4SUu-Bhkew-54hiJF1VPP8tfcQ
>
> Wifi APs, especially enterprise grade Wifi APs, frequently do arp and ND proxy, and they convert the responses from the proxy to unicast at the 802.11 layer. Sometimes they even only do unicast at the 802.11 layer and replicate all multicast into 802.11 unicasts. Frequently this is more efficient than multicast because of the differences between the basic rate encoding used for multicast packets vs the usually much higher density encoding used for unicast packets.
>
> That usually keeps things working well enough.

ND proxy shouldn't break DAD, as I understand RFC4389. So logically,
DAD is just as reliable as basic ND, right?

Brian

[David Farmer]

Sent from my iPhone

> On Jul 15, 2017, at 18:59, Brian E Carpenter <***@gmail.com> wrote:
>
>> On 16/07/2017 11:37, David Farmer wrote:
>>
>>>> On Jul 15, 2017, at 17:41, Brian E Carpenter <***@gmail.com> wrote:
>>>>
>>>>> On 16/07/2017 10:22, Nick Hilliard wrote:
>>>>> Ole Troan wrote:
>>>>> This a protocol problem. DAD is built with the assumption that
>>>>> physical links are reliable. 20% packet loss for multicast is common
>>>>> on wifi...
>>>>
>>>> most protocols will croak at 20% packet loss. If wifi cannot support
>>>> multicast properly, then this is an 802.11 problem rather than a problem
>>>> with DAD or any of the many other bits of ipv6 that depend on moderately
>>>> reliable multicast.
>>>
>>> I'm curious. If DAD has that problem, why doesn't Neighbor Discovery
>>> have an equally bad problem?
>>>
>>> BTW, Ole is correct. While testing the GRASP prototype at the last IETF,
>>> we discovered a high loss rate for LL multicast on the network.
>>> However, it wasn't primarily due to WiFi. It was due to intentional
>>> multicast throttling in the switches:
>>> https://mailarchive.ietf.org/arch/msg/anima/g4SUu-Bhkew-54hiJF1VPP8tfcQ
>>
>> Wifi APs, especially enterprise grade Wifi APs, frequently do arp and ND proxy, and they convert the responses from the proxy to unicast at the 802.11 layer. Sometimes they even only do unicast at the 802.11 layer and replicate all multicast into 802.11 unicasts. Frequently this is more efficient than multicast because of the differences between the basic rate encoding used for multicast packets vs the usually much higher density encoding used for unicast packets.
>>
>> That usually keeps things working well enough.
>
> ND proxy shouldn't break DAD, as I understand RFC4389. So logically,
> DAD is just as reliable as basic ND, right?

That is my understanding.

But I probably should have mentioned that older APs, especially older consumer grade APs, might not have any IPv6 support. So it might only do arp proxy, and ND and DAD could suck rocks, compared to arp. Also, another good reason to keep software updated.

Also, obviously adhoc mode WiFi has none of that as there are no APs.

[Ole Troan]

> On 16 Jul 2017, at 01:59, Brian E Carpenter <***@gmail.com> wrote:
>
>> On 16/07/2017 11:37, David Farmer wrote:
>>
>>>> On Jul 15, 2017, at 17:41, Brian E Carpenter <***@gmail.com> wrote:
>>>>
>>>>> On 16/07/2017 10:22, Nick Hilliard wrote:
>>>>> Ole Troan wrote:
>>>>> This a protocol problem. DAD is built with the assumption that
>>>>> physical links are reliable. 20% packet loss for multicast is common
>>>>> on wifi...
>>>>
>>>> most protocols will croak at 20% packet loss. If wifi cannot support
>>>> multicast properly, then this is an 802.11 problem rather than a problem
>>>> with DAD or any of the many other bits of ipv6 that depend on moderately
>>>> reliable multicast.
>>>
>>> I'm curious. If DAD has that problem, why doesn't Neighbor Discovery
>>> have an equally bad problem?
>>>
>>> BTW, Ole is correct. While testing the GRASP prototype at the last IETF,
>>> we discovered a high loss rate for LL multicast on the network.
>>> However, it wasn't primarily due to WiFi. It was due to intentional
>>> multicast throttling in the switches:
>>> https://mailarchive.ietf.org/arch/msg/anima/g4SUu-Bhkew-54hiJF1VPP8tfcQ
>>
>> Wifi APs, especially enterprise grade Wifi APs, frequently do arp and ND proxy, and they convert the responses from the proxy to unicast at the 802.11 layer. Sometimes they even only do unicast at the 802.11 layer and replicate all multicast into 802.11 unicasts. Frequently this is more efficient than multicast because of the differences between the basic rate encoding used for multicast packets vs the usually much higher density encoding used for unicast packets.
>>
>> That usually keeps things working well enough.
>
> ND proxy shouldn't break DAD, as I understand RFC4389. So logically,
> DAD is just as reliable as basic ND, right?

Wrong.
DAD is by default a single fire and forget packet.
If you by basic ND mean address resolution, then that retries three times. And the consequences of failure are quite different.

Ole

[Pascal Thubert (pthubert)]

I respectfully disagree.

There are a number of cases where an SDO designs on false assumptions of what the other is doing.

IPv6 ND expects that IEEE protocols can serve 2^24 Mulcair groups which enables DAD and discovery to be perfectly fine. ND also expects that the core service that 802.1 provides on Ethernet (reliable broadcast) extends to the whole ESS so we have our problems solved. Sadly, no such thing.

The same exists in the other direction as well. IEEE expects that the AP will implement a magical ND proxy and that solves the problem. Again, the IETF has no such thing, at least for ND. Some people at IEEE think that bridging 48bits address to 64bits addresses will enable bridging with all it's nice properties on 802.15.4 links. Good thing this illusion is dissolving rapidly.

The solution is probably to stop throwing our problems over the fence (thanks to Norm Finn for the quote). As they say, if_you_want_a_thing_done_well,_do_it_yourself<https://fr.m.wiktionary.org/w/index.php?title=if_you_want_a_thing_done_well,_do_it_yourself&action=edit&redlink=1>

The solution is probably to understand the IEEE design of an ESS for L2 operations and emulate it at L3. A step towards reconciliation of the designs may be to effectively provide the proxy that the IEEE expects to see at the boundary of the mediums.

All the best,

Pascal

Le 16 juil. 2017 ? 00:23, Nick Hilliard <***@foobar.org<mailto:***@foobar.org>> a ?crit :

Ole Troan wrote:
This a protocol problem. DAD is built with the assumption that
physical links are reliable. 20% packet loss for multicast is common
on wifi...

most protocols will croak at 20% packet loss. If wifi cannot support
multicast properly, then this is an 802.11 problem rather than a problem
with DAD or any of the many other bits of ipv6 that depend on moderately
reliable multicast.

Nick

[Ole Troan]

Pascal,

Agree with all you're saying.
The pragmatic solutions from our perspective is to treat the media as a set of point to point links with /64 to each host. Then all these problems of multicast, DAD etc magically disappear.

Ole

> On 16 Jul 2017, at 08:58, Pascal Thubert (pthubert) <***@cisco.com> wrote:
>
> I respectfully disagree.
>
> There are a number of cases where an SDO designs on false assumptions of what the other is doing.
>
> IPv6 ND expects that IEEE protocols can serve 2^24 Mulcair groups which enables DAD and discovery to be perfectly fine. ND also expects that the core service that 802.1 provides on Ethernet (reliable broadcast) extends to the whole ESS so we have our problems solved. Sadly, no such thing.
>
> The same exists in the other direction as well. IEEE expects that the AP will implement a magical ND proxy and that solves the problem. Again, the IETF has no such thing, at least for ND. Some people at IEEE think that bridging 48bits address to 64bits addresses will enable bridging with all it's nice properties on 802.15.4 links. Good thing this illusion is dissolving rapidly.
>
> The solution is probably to stop throwing our problems over the fence (thanks to Norm Finn for the quote). As they say, if_you_want_a_thing_done_well,_do_it_yourself
>
> The solution is probably to understand the IEEE design of an ESS for L2 operations and emulate it at L3. A step towards reconciliation of the designs may be to effectively provide the proxy that the IEEE expects to see at the boundary of the mediums.
>
> All the best,
>
> Pascal
>
> Le 16 juil. 2017 à 00:23, Nick Hilliard <***@foobar.org> a écrit :
>
>> Ole Troan wrote:
>>> This a protocol problem. DAD is built with the assumption that
>>> physical links are reliable. 20% packet loss for multicast is common
>>> on wifi...
>>
>> most protocols will croak at 20% packet loss. If wifi cannot support
>> multicast properly, then this is an 802.11 problem rather than a problem
>> with DAD or any of the many other bits of ipv6 that depend on moderately
>> reliable multicast.
>>
>> Nick
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ***@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------

[Pascal Thubert (pthubert)]

I can certainly sense the irony in asserting there’s such magic.

For instance, which magic makes it so that we would trust better DHCP(-PD) for handing a unique 16-bits word of prefix space as opposed to a unique 64bits word of IID space? In my book, that is effectively harder since you cannot rely for long on LRU to delay reassigning a previously assigned word, you get little help from entropy to cover for your mistakes and race conditions, etc
.

Also, at the prefix level, we do not have DAD as the “ultimate” protection against our automated or manual assignment mistakes; routing is not deterred by duplication, it just sees 2 advertisements as alternate ways to get there. Which means that if a /64 is duplicated, packets will be delivered to the nearest of the 2 owners from the perspective of the source. Not a great benefit from the current situation.

So certainly you want to qualify when an idea such as a /64 or shorter for all applies particularly well (e.g. an event starting with a clean slate, with less connected devices in the public than available prefixes, and a clear end of time when all prefixes are released), and when it shows limits. Coming from the very different ground of IoT, and though I am quite convinced by that particular idea, I do not believe in a one-fits-it-all solution.

I’d really love to see a draft that documents a set of reference models (profiles?) to help our users deploy an IPv6 campus network that meets their expectations. Routing to the /64 is definitely a great one.

We have some others in the IOT space to serve different use cases involving very long term deployments, large numbers of devices, dotting line state of connectivity, mobility, and drastically limited capability to do complex stuff such as IPv6 renumbering. To serve such use cases, we are effectively specifying ND operation and proxy. I do not see that as competition to the /64 approach. It is in fact following the common idea to reintroduce some routing when we hit the limits of bridging.

This has consequences. As we get rid of the illusion of the free and spanning broadcast domain, we need to reconsider how we apply protocols that used to rely on L2 broadcast. I expect to see more and more proxies showing up, like those on the works for ND or DNS SD.

All in all, I fully agree on the fundamentals beneath what you’re saying, that routing must be reintroduced at the borders of L2 networks when the L2 capabilities are so widely different that bridging would fail to provide the expected L2 services end-to-end, typically broadcast. We have opened the Pandora Box, illusions are dissolving, and solutions are emerging. Great stuff.

Take care,

Pascal


From: Ole Troan [mailto:***@employees.org]
Sent: dimanche 16 juillet 2017 10:48
To: Pascal Thubert (pthubert) <***@cisco.com>
Cc: Nick Hilliard <***@foobar.org>; ***@ietf.org
Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: <draft-ietf-6man-rfc4291bis-09.txt>)

Pascal,

Agree with all you're saying.
The pragmatic solutions from our perspective is to treat the media as a set of point to point links with /64 to each host. Then all these problems of multicast, DAD etc magically disappear.

Ole

On 16 Jul 2017, at 08:58, Pascal Thubert (pthubert) <***@cisco.com<mailto:***@cisco.com>> wrote:
I respectfully disagree.

There are a number of cases where an SDO designs on false assumptions of what the other is doing.

IPv6 ND expects that IEEE protocols can serve 2^24 Mulcair groups which enables DAD and discovery to be perfectly fine. ND also expects that the core service that 802.1 provides on Ethernet (reliable broadcast) extends to the whole ESS so we have our problems solved. Sadly, no such thing.

The same exists in the other direction as well. IEEE expects that the AP will implement a magical ND proxy and that solves the problem. Again, the IETF has no such thing, at least for ND. Some people at IEEE think that bridging 48bits address to 64bits addresses will enable bridging with all it's nice properties on 802.15.4 links. Good thing this illusion is dissolving rapidly.

The solution is probably to stop throwing our problems over the fence (thanks to Norm Finn for the quote). As they say, if_you_want_a_thing_done_well,_do_it_yourself<https://fr.m.wiktionary.org/w/index.php?title=if_you_want_a_thing_done_well,_do_it_yourself&action=edit&redlink=1>

The solution is probably to understand the IEEE design of an ESS for L2 operations and emulate it at L3. A step towards reconciliation of the designs may be to effectively provide the proxy that the IEEE expects to see at the boundary of the mediums.

All the best,

Pascal

Le 16 juil. 2017 à 00:23, Nick Hilliard <***@foobar.org<mailto:***@foobar.org>> a écrit :
Ole Troan wrote:

This a protocol problem. DAD is built with the assumption that
physical links are reliable. 20% packet loss for multicast is common
on wifi...

most protocols will croak at 20% packet loss. If wifi cannot support
multicast properly, then this is an 802.11 problem rather than a problem
with DAD or any of the many other bits of ipv6 that depend on moderately
reliable multicast.

Nick

--------------------------------------------------------------------
IETF IPv6 working group mailing list
***@ietf.org<mailto:***@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

[Nick Hilliard]

Ole Troan wrote:
> Agree with all you're saying.

so the assumptions of reasonable network-layer reliability have not been
implemented in 802.11 for multicast, the combination of which is now
causing protocols which depend on that reliability to break. What a mess.

draft-mcbride-mboned-wifi-mcast-problem-statement was written up some
while back and describes some of these problems. It would be useful to
see some progress on this.

> The pragmatic solutions from our perspective is to treat the media as a
> set of point to point links with /64 to each host. Then all these
> problems of multicast, DAD etc magically disappear.

or virtual network segmentation using multicast->unicast replication at
the AP using some form of multicast proxy. Neither these solutions
would work for point-to-point wifi.

All this is outside the context of rfc4291bis though.

Nick

[Manfredi, Albert E]

> Just in case you missed it, I'm advocating that 64 bit IIDs only
> apply to SLAAC and not to DHCPv6 IA_NA.

That's good. It's a good compromise. I'm all for it.

> Note that I believe Lorenzo's argument is valid. The reason we can
> expect a/64 to be there is that SLAAC requires a /64. If we relax
> that requirement then soon we will see longer prefixes pop up and
> are back to square one.

SLAAC currently requires whatever IID length applies to the link, which still comes out to 64 bits for Ethernet (but for reasons that no longer apply). So, we have agreed, I think, to retain this 64-bit IID requirement for SLAAC, as a self-imposed measure. Part of this compromise.

We agreed that relaxing that requirement for SLAAC would make it too easy to "race to the bottom."

This is all good, I think.

Bert

[Fred Baker]

Sent using a machine that autocorrects in interesting ways...

> On Jul 12, 2017, at 6:42 PM, Brian E Carpenter <***@gmail.com> wrote:
>
>> On 13/07/2017 06:32, Manfredi, Albert E wrote:
>> ...
>> Of course, the other option is to expand using ULAs, but then, that's "so IPv4."
>
> Not. ULA doesn't imply NAT. It just implies private addresses.

I would go a step further. A ULA is a global-scope address that is not advertised in BGP, and if advertised is refused, barring private arrangements. I carry a T-Mobile telephone, and the address of the DNS server is a ULA address. The point, I have no doubt, is to prevent attacks on the server by having it untraceable absent a legitimate reason to have the address.

It's a firewall rule that is programmed in routing instead of a firewall. Nothing more, and nothing less.

[Lorenzo Colitti]

On Wed, Jul 12, 2017 at 11:39 AM, Brian E Carpenter <
***@gmail.com> wrote:

> The advantage of requiring or recommending 64 bits is that it avoids the
> debate about N. I prefer 'recommend' because it avoids enumerating all
> possible exceptions. We've seen how hard it is to wordsmith the exceptions.
>

What's hard is not wordsmithing the exceptions.

What's hard is claiming that there's consensus (even rough consensus). The
fact of the matter is that we have opposing camps with equally strong
opinions on the matter, and neither camp is willing to accept the position
of the other.

Based on past experience, it seems pretty clear to me that this situation
will not change until we get a problem statement that we agree on. Care to
write one up?

[神明達哉]

At Wed, 12 Jul 2017 22:53:48 +0900,
Lorenzo Colitti <***@google.com> wrote:

> > The advantage of requiring or recommending 64 bits is that it avoids the
> > debate about N. I prefer 'recommend' because it avoids enumerating all
> > possible exceptions. We've seen how hard it is to wordsmith the exceptions.
>
> What's hard is not wordsmithing the exceptions.
>
> What's hard is claiming that there's consensus (even rough consensus). The
> fact of the matter is that we have opposing camps with equally strong
> opinions on the matter, and neither camp is willing to accept the position
> of the other.

Right, but in terms of advancing rfc4291bis as an Internet Standard, I
still have a feeling that the wg has been distracted with out-of-scope
matters too heavily. In my understanding the primary reason why
rfc4291bis was sent back to the wg after passing WGLC is that
conflicts between
- an "opposing camp" who wants to justify their practice of using
non-64 prefix in their operation (and most likely for manually
configured addresses)
- another "opposing camp" who wants to keep the IID length to be 64
bits as much as possible

And, my high-level understanding is that both camps seem to accept a
compromise to make the manual-configuration case an exception. In
that sense I still see a possibility of consensus and moving forward.
And, in that case it's generally a matter of wordsmithing.

But since the original pushback there have been other arguments of
whether the length of IIDs should be even more flexible. If this had
to be resolved for rfc4291bis to move forward, I agree we can't reach
a consensus at least without stepping back very far (and, in that
case, IMO it's even better to declare the failure of rfc4291bis
instead of wasting more time in this context). But, IMO, this
discussion should have been out of scope of rfc4291bis - after all
there's virtually no implementation that has this flexibility in SLAAC
(where IID matters most), let alone multiple independent
such implementations that are interoperable. So, due to the
conservative nature of rfc4291bis any such discussions should have
been a post-rfc4291bis fodder. Unfortunately, most of the recent
discussions in this thread seem to be spent on this topic.

So I hope we can now focus on the matter of the very original clash
and see if we can reach consensus through some wordsmithing. If we
can't even do that I think it's better to drop rfc4291bis at this
point. If people still have energy on this topic after that we can
try to write up a problem statement or whatever for a fresh restart.
Meanwhile some others in the wg can use their time for some other,
possibly more practically important things such as header insertion
matters.

> Based on past experience, it seems pretty clear to me that this situation
> will not change until we get a problem statement that we agree on. Care to
> write one up?

--
JINMEI, Tatuya

[Lorenzo Colitti]

On Thu, Jul 13, 2017 at 2:24 AM, 神明達哉 <***@wide.ad.jp> wrote:

> So I hope we can now focus on the matter of the very original clash
> and see if we can reach consensus through some wordsmithing. If we
> can't even do that I think it's better to drop rfc4291bis at this
> point.


Agreed on both counts.

[Brian E Carpenter]

On 13/07/2017 01:53, Lorenzo Colitti wrote:
> On Wed, Jul 12, 2017 at 11:39 AM, Brian E Carpenter <
> ***@gmail.com> wrote:
>
>> The advantage of requiring or recommending 64 bits is that it avoids the
>> debate about N. I prefer 'recommend' because it avoids enumerating all
>> possible exceptions. We've seen how hard it is to wordsmith the exceptions.
>>
>
> What's hard is not wordsmithing the exceptions.
>
> What's hard is claiming that there's consensus (even rough consensus). The
> fact of the matter is that we have opposing camps with equally strong
> opinions on the matter, and neither camp is willing to accept the position
> of the other.
>
> Based on past experience, it seems pretty clear to me that this situation
> will not change until we get a problem statement that we agree on. Care to
> write one up?
>

Nick Hilliard just did:

>> I would suggest that future protocols need to define what makes sense
>> for them, and mandating a constant in advance isn't necessary or even
>> appropriate.

Which is why I personally would be happy with the addressing
architecture either not mentioning 64 at all, or *recommending* 64,
or requiring 64 "except if the first three bits
of the address are 000, or when the addresses are manually
configured, or by exceptions defined in standards track documents."

IMHO any of those three formulations would resolve Nick's problem
statement (given that there is also a citation of BCP198 in the
latest draft to clarify how routing works).

Brian

[Lorenzo Colitti]

On Thu, Jul 13, 2017 at 11:05 AM, Brian E Carpenter <
***@gmail.com> wrote:

> > Based on past experience, it seems pretty clear to me that this situation
> > will not change until we get a problem statement that we agree on. Care
> to
> > write one up?
>
> Nick Hilliard just did:
>
> >> I would suggest that future protocols need to define what makes sense
> >> for them, and mandating a constant in advance isn't necessary or even
> >> appropriate.
>

I said "a problem statement we're likely to agree on".

"X isn't necessary or even appropriate" is a heavily subjective statement.
The other camp in this discussion finds X very much necessary and
appropriate, and the conversation never goes anywhere. You could substitute
"X" with "a fixed boundary" or "a variable boundary" and both sentences
read perfectly well.

An example of a problem statement that is be easier to agree on is "X
causes problems A, B, and C, which we would like to solve".

[Simon Hobson]

Mark Smith <***@gmail.com> wrote:

> This is not recognising that there are more than operational or functional properties of addresses. They have privacy and security properties too.

Shouldn't this requirement be separate from the underlying protocol requirements ?

Ignoring LL addresses, it seems that only self assigned addresses using deprecated methods (ie based on hardware address) actually *require* a 64 bit split. So on that basis, the standard defining how the protocols work should require implementations to support an arbitrary split.

Separate to that (in a separate section), make recommendations (as in "should") to support security and privacy.

[Joel M. Halpern]

If we keep the self-genereated IID length at 64 bits, then folks can
work otu different methods for making use of it, and see what the value is.
if we say taht the length is defined by something the network, then we
need to work out what we have to tell people to make that safe to do.
We also restrict people's ability to innovate in the host stack (which
is where, as I understand it, we want to see innovation.)

If we were short of bits, sure, freeing up bits might make sense. But
why do so in the absence of such a shortage?

Yours,
Joel

On 7/12/17 9:47 AM, Simon Hobson wrote:
> Mark Smith <***@gmail.com> wrote:
>
>> This is not recognising that there are more than operational or functional properties of addresses. They have privacy and security properties too.
>
> Shouldn't this requirement be separate from the underlying protocol requirements ?
>
> Ignoring LL addresses, it seems that only self assigned addresses using deprecated methods (ie based on hardware address) actually *require* a 64 bit split. So on that basis, the standard defining how the protocols work should require implementations to support an arbitrary split.
>
> Separate to that (in a separate section), make recommendations (as in "should") to support security and privacy.
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ***@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

[Mark Smith]

On 12 July 2017 at 23:47, Simon Hobson <***@thehobsons.co.uk> wrote:
> Mark Smith <***@gmail.com> wrote:
>
>> This is not recognising that there are more than operational or functional properties of addresses. They have privacy and security properties too.
>
> Shouldn't this requirement be separate from the underlying protocol requirements ?
>

No, I don't think so. These protocols fundamentally exist to serve
end-user needs. If they don't, then they're no more than an academic
experiment, and we'll have wasted an awful lot of human capital on
them. These are primary protocol requirements, necessary to meet to
justify the protocol's existence.


> Ignoring LL addresses, it seems that only self assigned addresses using deprecated methods (ie based on hardware address) actually *require* a 64 bit split. So on that basis, the standard defining how the protocols work should require implementations to support an arbitrary split.
>

I think the final arbiter in any of these situations is "what is best
for the end-users?"

What is the simplest, that will result in lower network capex and opex
costs to the end-users who directly or indirectly pay those costs?

What is the most reliable and robust, so that when an end user
connects to and uses the network, they're least likely to encounter
issues for which they do not have the technical skillsets to resolve?

> Separate to that (in a separate section), make recommendations (as in "should") to support security and privacy.
>

We've tried that before, making security and privacy optional to
implement makes it easy to justify not implementing it.

We need to have the Internet secure and private by default. If we make
them options, we should make them options that have to be turned off
rather than on, because that causes the person to make an active and
conscious decision to give them up (whether it is the right decision
for their context is separate, and not one we can control or forecast.
If they're unsure, we are providing the safest default.)

BCP188/RFC7258 is stating that we take this secure and private by
default approach:

"The IETF will strive to produce specifications that mitigate
pervasive monitoring attacks."


Although RFC1726, "Technical Criteria for Choosing IP The Next
Generation (IPng)", doesn't specifically call out privacy, privacy is
a component of security, and it stated that:

"Security should be an integral component of any IPng from the beginning."

It is evident from the Snowden revelations that we dropped the ball on
that (e.g., IPsec was dropped as an implementation requirement per
RFC6434 and became an option), we now need correct that mistake and
take a security and privacy first and by default approach.

Regards,
Mark.

[Simon Hobson]

Re-ordering the comments slightly ...

Mark Smith <***@gmail.com> wrote:

>> Ignoring LL addresses, it seems that only self assigned addresses using deprecated methods (ie based on hardware address) actually *require* a 64 bit split. So on that basis, the standard defining how the protocols work should require implementations to support an arbitrary split.
>>
>
> I think the final arbiter in any of these situations is "what is best
> for the end-users?"
>
> What is the simplest, that will result in lower network capex and opex
> costs to the end-users who directly or indirectly pay those costs?
>
> What is the most reliable and robust, so that when an end user
> connects to and uses the network, they're least likely to encounter
> issues for which they do not have the technical skillsets to resolve?

The obvious answer to that is "all implementations MUST handle any IID length". That way, when a device does get connected to a network where the IID length isn't 64 bits - it'll still work.
If you leave in any suggestion that an implementation can assume a split 64/64 then some implementations are going to have that embedded in them. If you allow that, and the device gets connected to a network where that isn't the case (for whatever reason*) then it's going to "not work" (either at all or properly).

* We've already seen some suggestions of why that might be - for example where an ISP only provides a single /64 and the user wants more than one network.


>>> This is not recognising that there are more than operational or functional properties of addresses. They have privacy and security properties too.
>>
>> Shouldn't this requirement be separate from the underlying protocol requirements ?
>
> No, I don't think so. These protocols fundamentally exist to serve
> end-user needs. If they don't, then they're no more than an academic
> experiment, and we'll have wasted an awful lot of human capital on
> them. These are primary protocol requirements, necessary to meet to
> justify the protocol's existence.

But that's the point I was making - having the IID length at (say) 64 bits is NOT a fundamental requirement. Things would still work just fine even if it was (say) 32 bits, or 16 bits, or ... With shorter lengths (smaller address space) the problem of creating addresses autonomously without clashes becomes harder - but other than that, as long as there is "enough" space then devices will still work.

Where the large address space requirement comes from is a secondary function - privacy. It is not in any way a fundamental limitation in shifting packets about.

> Separate to that (in a separate section), make recommendations (as in "should") to support security and privacy.
>>
>
> We've tried that before, making security and privacy optional to
> implement makes it easy to justify not implementing it.

I think there's something of a difference between an optional feature - ie something that needs to be added - and something where it's not a feature that's turned on or off. And the IID length would need to be a lot shorter than 64 bits before the address space becomes trivially smaller. You can't really say the privacy feature is "off" if the IID is only 63 bits, or even down to (say) 32 bits which still gives 4 billion addresses to play with.

If the recommendation is for 64 bits, then it's going to be hard to justify such a small address space that privacy is nullified. And the sort of outfit that does, will be quite happy to do other crap that's harmful to their users - regardless of what any RFC says.

So if you're going to set some arbitrary sizes for IID lengths - then give the real reason which is security/privacy. Because AIUI there is no other fundamental reason to set any restrictions.

[Simon Hobson]

"Manfredi, Albert E" <***@boeing.com> wrote:

> The problem I have is mainly that in the ebb and flow of these continuing discussions, one sees the "IIDs must be 64 bits wide" creeping back in, again and again. Where instead, the rough consensus seems to have become, must be 64-bits wide unless the addresses are statically configured or are provided by DHCPv6. In the latter cases, 64-bit IIDs might still be "recommended," but in fact, the on-link prefix length can be from zero to 128 bits, and the IID must therefore be 128 - prefix length.

I'd go further ...
While I've not been following the detail too closely, I get the feeling that SLAAC for global addressing BASED ON HARDWARE ADDRESS, and link local addresses, need 64 bits, nothing else actually does. On that basis, surely the better way to express it would be to say that in general there is no restriction as to where the prefix/id split falls - but some addressing methods have specific requirements. And in reality, link local addresses are pretty irrelevant in terms of how you manage other addresses as they have their own prefix and semantics.

If you say "it must be 64 bits except for X and Y" then if someone comes along in the future with a spiffing idea for method Z - then the whole merry go round of discussion starts up again getting "that changed to "... except for X and Y and Z".

Ie, unless there is some fundamental reason why the split MUST be at 64 bits, then simply say there isn't a requirements except where noted in the RFCs for the addressing methods that DO have a requirements for a specific length. IMO that's the cleaner way of expressing it.
If there are reasons why it's a good idea to use 64 bits - such as because there are implementations out there that make that assumption - then point them out (with a "for reasons of A, B, C is is recommended that ..." paragraph) rather than using them as a reason to maintain something that doesn't seem to make much sense now.



David Farmer <***@umn.edu> wrote:

> IPv6 as currently defined does actually require IIDs to be 64 bits, if this wasn't the case then you could use subnets of any length without any special requirements or considerations.

And so we come back to (what appears to me to be) the fundamental problem. At some point, for whatever reason, it was written that the split must be at 64 bits. Now it seems that in the general case there is no such requirement - but that CERTAIN ADDRESSING MODES/PROTOCOLS or IMPLEMENTATIONS require it to be at 64 bits.

So if the argument is that "we can't change 'something' because it clashes with 'something else'" - then isn't that an argument for 'correcting' the something else ?


> So, how about something like this;
> ...
> Oops, forgot something;
>
> For the full functioning of all IPv6 capabilities, when assigning unicast addresses, except those that start with the binary value 000, Interface Identifiers are required to be 64 bits long. The rationale for using 64 bit Interface Identifiers can be found in [RFC7421]. However, as IPv6 unicast routing and on-link determination are separate from address assignment and will operate with Interface Identifiers of any length. It is therefore possible, with several limitations, to use Interface Identifiers of other lengths in limited scenarios, these include; 128 bit prefixes, such as for router loopback addresses, point-to-point router-links [RFC6164], and links where all node are manually configured.

As it read the discussions, it's not so much a case of "in limited scenarios", but a case of "where an addressing mode requiring a specific IID length is not in use".

Al Albert writes, it seems that there's a desperation to hang on to 64 bits but allow some exceptions (and somehow imply that even when these exceptions apply, then it's a really really bad idea to depart from 64 bits - rather than simply drop the requirement and move it to where it actually applies (in the definition of those features/protocols that require it).



Just for completeness I'll add that my experience with IPv4 started more or less after classless addresses was the norm. In a parallel to the bit above about implementations having hardcoded assumptions, it came as "a surprise" to me when I came across a piece of equipment (an oldish serial terminal server) that refused to allow a /23 in the 192.168 RFC1918 range as it had hard-coded assumptions about address classes. That was the only time I came across such an issue - other than Cisco course content still stuck in classful mode even after the whole world set their routers to allow classless (and IP subnet zero) as the first step in configuring a router.

[Ole Troan]

Brian,

> On 11 Jul 2017, at 01:10, Brian E Carpenter <***@gmail.com> wrote:
>
> Neither of our WG Chairs is neutral on this issue; one is the
> document editor, the other has a clear opinion, to which he is
> completely entitled. Personally, I think the AD could step
> in to judge consensus.

What is my opinion? Could you please summarize?
It might be clearer to you than me. :-)

Ole

[Brian E Carpenter]

Ole,

It seems to me that you have always been indicating that you think the text
should say, effectively, that the IID length MUST be 64 (except for the
well know exceptions).

I apologise if that is incorrect.

Regards
Brian

On 12/07/2017 03:22, Ole Troan wrote:
> Brian,
>
>> On 11 Jul 2017, at 01:10, Brian E Carpenter <***@gmail.com> wrote:
>>
>> Neither of our WG Chairs is neutral on this issue; one is the
>> document editor, the other has a clear opinion, to which he is
>> completely entitled. Personally, I think the AD could step
>> in to judge consensus.
>
> What is my opinion? Could you please summarize?
> It might be clearer to you than me. :-)
>
> Ole
> .
>

[Suresh Krishnan]

Hi Brian,

> On Jul 10, 2017, at 7:10 PM, Brian E Carpenter <***@gmail.com> wrote:
> ...
> Personally, I think the AD could step
> in to judge consensus.

Yes. I have refrained from actively discussing this topic in order to leave this option open for me if it is required. I sincerely hope that the WG can come to consensus on this issue, though.

Thanks
Suresh

[神明達哉]

At Sun, 9 Jul 2017 16:09:14 -0500,
David Farmer <***@umn.edu> wrote:

> So, What should we say in RFC4291bis? Personally I'd prefer we eliminate
> the term subnet from RFC4291bis, but assuming that won't happen how about
> the following;

I'm not sure if we still want to continue wordsmith rather than either
accept the current text or give up advancing the address architecture,
but otherwise I largely like your text. A few comments:

> Currently, IPv6 continues the IPv4 model in that a subnet prefix is
> associated with one link. Multiple subnet prefixes may be assigned to the
> same link. The relationship between links and IPv6 subnet prefixes differs
> from the IPv4 model in that the prefixes used for on-link determination are
> separate and may differ from the assigned subnet prefixes. However, on-link
> prefixes identical with assigned subnet prefixes are recommended. A prefix
> length associated with a manually configured address determines the on-link
> prefix associated with the manually configured address. See [RFC5942] "The
> IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes" for
> more details.

I'd interpret the last two sentences as RFC5942 indicating:

A prefix length associated with a manually configured address
determines the on-link prefix associated with the manually
configured address. (*)

If I'm correct, while I agree on (*) it's not obvious to me that
RFC5942 directly suggests this observation. Some more explanation
would help here.

> Note: Any on-link prefixes longer than a covering assigned subnet prefix
> must be associated with the same link as the assigned subnet prefix. Also,
> any assigned subnet prefixes longer than a covering on-link prefix must be
> associated with the same link as the on-link prefix.

I'm afraid the meaning of "associated with" is not very clear here.

> When forming or assigning unicast addresses, except those that start with
> the binary value 000, Interface IDs are required to be 64 bits long. The
> rationale for using 64 bit Interface Identifiers can be found in [RFC7421].

Personally I prefer this text over the one in rfc4291bis-09:

Interface Identifiers are 64 bit long except if the first three bits
of the address are 000, or when the addresses are manually
configured, or by exceptions defined in standards track documents.
The rationale for using 64 bit Interface Identifiers can be found in
[RFC7421]. An example of a standards track exception is [RFC6164]
that standardises 127 bit prefixes on inter-router point-to-point
links.

since IMO "a compromise between excessive rigidity and excessive
flexibility" is actually already provided in the existing spec and all
we need is a clarification rather than tweaking the definition and
listing awkward exceptions. But I'm not sure if your version of text
is acceptable for "draft-bourbaki-6man-classless-ipv6" authors.
Hopefully this note clears any doubt from them:

> Note: the previous paragraph implies nothing about on-link determination
> which as discussed in section 2.1 is separate from subnet assignment in
> IPv6.

but we may need to explain it in more detail at the risk of sounding
too verbose.

--
JINMEI, Tatuya

[David Farmer]

On Mon, Jul 10, 2017 at 1:53 PM, 神明達哉 <***@wide.ad.jp> wrote:

> At Sun, 9 Jul 2017 16:09:14 -0500,
> David Farmer <***@umn.edu> wrote:
>
> > So, What should we say in RFC4291bis? Personally I'd prefer we eliminate
> > the term subnet from RFC4291bis, but assuming that won't happen how about
> > the following;
>
> I'm not sure if we still want to continue wordsmith rather than either
> accept the current text or give up advancing the address architecture,
> but otherwise I largely like your text. A few comments:
>
> > Currently, IPv6 continues the IPv4 model in that a subnet prefix is
> > associated with one link. Multiple subnet prefixes may be assigned to the
> > same link. The relationship between links and IPv6 subnet prefixes
> differs
> > from the IPv4 model in that the prefixes used for on-link determination
> are
> > separate and may differ from the assigned subnet prefixes. However,
> on-link
> > prefixes identical with assigned subnet prefixes are recommended. A
> prefix
> > length associated with a manually configured address determines the
> on-link
> > prefix associated with the manually configured address. See [RFC5942]
> "The
> > IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes"
> for
> > more details.
>
> I'd interpret the last two sentences as RFC5942 indicating:
>
> A prefix length associated with a manually configured address
> determines the on-link prefix associated with the manually
> configured address. (*)
>
> If I'm correct, while I agree on (*) it's not obvious to me that
> RFC5942 directly suggests this observation. Some more explanation
> would help here.
>

I intended the reference to RFC5942 to cover the whole paragraph, not just
the next to the last sentence.

As for manual configuration, RFC5942 says;

A host considers a prefix to be on-link only
through explicit means, such as those specified in the on-link
definition in the Terminology section of [RFC4861] (as modified
by this document) or via manual configuration. Note that the
requirement for manually configured addresses is not explicitly
mentioned in [RFC4861].

While that doesn't explicitly say "A prefix length associated with a
manually configured address determines the on-link prefix associated with
the manually configured address." in my opinion it strongly implies it.
How else would you provide an on-link prefix for a manually configures
address otherwise? Also, I think this need to be said explicitly some
place. But if you have suggestion to clarify, I'd be interested to here
them.


> > Note: Any on-link prefixes longer than a covering assigned subnet prefix
> > must be associated with the same link as the assigned subnet prefix.
> Also,
> > any assigned subnet prefixes longer than a covering on-link prefix must
> be
> > associated with the same link as the on-link prefix.
>
> I'm afraid the meaning of "associated with" is not very clear here.
>

I'm open to other words, suggestions.


> > When forming or assigning unicast addresses, except those that start with
> > the binary value 000, Interface IDs are required to be 64 bits long. The
> > rationale for using 64 bit Interface Identifiers can be found in
> [RFC7421].
>
> Personally I prefer this text over the one in rfc4291bis-09:
>
> Interface Identifiers are 64 bit long except if the first three bits
> of the address are 000, or when the addresses are manually
> configured, or by exceptions defined in standards track documents.
> The rationale for using 64 bit Interface Identifiers can be found in
> [RFC7421]. An example of a standards track exception is [RFC6164]
> that standardises 127 bit prefixes on inter-router point-to-point
> links.
>
> since IMO "a compromise between excessive rigidity and excessive
> flexibility" is actually already provided in the existing spec and all
> we need is a clarification rather than tweaking the definition and
> listing awkward exceptions. But I'm not sure if your version of text
> is acceptable for "draft-bourbaki-6man-classless-ipv6" authors.
> Hopefully this note clears any doubt from them:
>
> > Note: the previous paragraph implies nothing about on-link determination
> > which as discussed in section 2.1 is separate from subnet assignment in
> > IPv6.
>
> but we may need to explain it in more detail at the risk of sounding
> too verbose.
>

More detail here? Or, in 2.1? Which is the paragraph above with the
reference to RFC5942.


> --
> JINMEI, Tatuya
>

Thanks

--
===============================================
David Farmer Email:***@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: [phone] <(612)%20626-0815>
Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952>
===============================================

[神明達哉]

At Mon, 10 Jul 2017 15:16:46 -0500,
David Farmer <***@umn.edu> wrote:

> While that doesn't explicitly say "A prefix length associated with a
> manually configured address determines the on-link prefix associated with
> the manually configured address." in my opinion it strongly implies it.
> How else would you provide an on-link prefix for a manually configures
> address otherwise? Also, I think this need to be said explicitly some
> place. But if you have suggestion to clarify, I'd be interested to here
> them.

Regardless of how strongly (if at all) RFC5942 implies that, I agree
it's good to note it explicitly in some place. As for suggested text,
I'll hold off for now - at this moment it's not even clear we (wg)
agree on the need for further wordsmith.

--