Subject: Re: Comments on draft-ietf-6man-default-iids-01.txt

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Nov 2014 17:45:24 -1000

Hi, Ralph,

Thanks so much for your feedback! (and apologies for the delay in my
response)...

On 10/27/2014 08:03 AM, Ralph Droms (rdroms) wrote:
> In this document, I think it is important to be explicit about the
> considerations that might lead to a decision not to follow the RFC
> 2119 language recommendations in this document.  My immediate concern
> is the 6LoWPAN standards, which use IIDs based on hardware addresses
> as a method for IPv6 header compression.

My personal take (also rather off-topic, you might argue) is that while
the MAC address has been typically embedded in the IID, one cannot
really (architecturally speaking) expect that to be the case. -- but
yes, this is kind of off-topic.

> As an editorial detail, the document lists the various RFCs that are
> update, but does not explicitly state what is to be updated in those
> documents.  While the updates could be reasonably inferred, seems to
> me an explicit statement about what is to be updated would be good.

Essentially, what we're updating is how Interface IDs should be
generated for such technologies. Quoting the text to be replaced would
make this document ugly... mm.. maybe just mention the relevant
section(s)? Something else?

(i.e., I understand your point, but do not (yet) see a cleaner way to do
that than the one (rather vague, if you want) that we're currently
employing) -- i.e., ideas are welcome.

> With those comments in mind, I'll suggest the following text
> changes:
> 
> In section 1, add this paragraph before the "NOTE":
> 
> In some network technologies and adaptation layers, the use of an IID
> based on a hardware address offers some advantages.  For example, the
> IP-over-IEEE802.15.4 standard in RFC6775 allows for compression of
> IPv6 addresses when the IID the address is based on the corresponding
> hardware address.  The design and engineering tradeoffs between
> security and privacy, and network efficiency should be considered in
> any decision about the use of an IID based on a hardware address.

I'm personally fine with haing an exception for say 6775 and similar
technologies. However, as noted above, I'm not sure I'd state it as
suggested - i.e., trading efficiency for security & privacy.

> Replace section 3 with:
> 
> It is RECOMMENDED by this document that nodes implement and employ 
> RFC 7217 as the default scheme for generating stable IPv6 addresses 
> with SLAAC.  Some specifications MAY use a an IID based on a node's 
> hardware address if design and engineering considerations warrant.
> 
> It is RECOMMENDED by this document that nodes do not employ IPv6 
> address generation schemes that embed the underlying hardware address
> in the Interface Identifier.  In particular, this document RECOMMENDS
> that nodes do not generate Interface Identifiers with the schemes
> specified in [RFC2464], [RFC2467], [RFC2470], [RFC2491], [RFC2492],
> [RFC2497], [RFC2590], [RFC3146], [RFC3572], [RFC4338], [RFC4391],
> [RFC5121], and [RFC5072], and updates those documents with this
> recommendation.
> 
> It is RECOMMENDED by this document that future specifications no not
> specify IPv6 address generation schemes that embed the underlying
> hardware address in the Interface Identifier. Future specifications
> MAY use a an IID based on a node's hardware address if design and
> engineering considerations warrant.

Overall, the above seem fine to me. What do other folks think?

> In section 4, replace the last paragraph with:
> 
> Future revisions or updates of these documents should take the issues
> of privacy and security mentioned in section 1 and explain any design
> and engineering considerations that lead to the use of IIDs based on
> a node's hardware address.

This seems fine, too.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Dave Thaler <[email-masked]>
Date: Tue, 11 Nov 2014 20:13:36 +0000

My opinion is that link layers MUST define a mechanism that provides privacy.
A link layer MAY also define a mechanism that is more efficient and does not
provide privacy.   The choice of whether to enable privacy or not SHOULD be
configurable in such a case.

-Dave

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Fernando Gont
> Sent: Monday, November 10, 2014 5:45 PM
> To: Ralph Droms (rdroms); 6man WG
> Cc: [email-masked]
> Subject: Re: Comments on draft-ietf-6man-default-iids-01.txt
> 
> Hi, Ralph,
> 
> My personal take (also rather off-topic, you might argue) is that while the
> MAC address has been typically embedded in the IID, one cannot really
> (architecturally speaking) expect that to be the case. -- but yes, this is kind of
> off-topic.
> 
> Essentially, what we're updating is how Interface IDs should be generated for
> such technologies. Quoting the text to be replaced would make this document
> ugly... mm.. maybe just mention the relevant section(s)? Something else?
> 
> (i.e., I understand your point, but do not (yet) see a cleaner way to do that
> than the one (rather vague, if you want) that we're currently
> technologies. However, as noted above, I'm not sure I'd state it as suggested -
> i.e., trading efficiency for security & privacy.
> 
> 
> 
> > Replace section 3 with:
> >
> RFC
> > 7217 as the default scheme for generating stable IPv6 addresses with
> > SLAAC.  Some specifications MAY use a an IID based on a node's
> > and engineering considerations that lead to the use of IIDs based on a
> > node's hardware address.
> 
> This seems fine, too.
> 
> Thanks!
> 
> Best regards,
> --
> Fernando Gont
> SI6 Networks
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Nov 2014 11:07:14 -1000

> configurable in such a case.

FWIW, I fully agree with Dave's view.

Thanks,

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 11 Nov 2014 17:25:23 -0500

Fernando,

Comments inline...

On Mon, Nov 10, 2014 at 10:45 PM, Fernando Gont <[email-masked]>
wrote:

> Have you read RFC 6282?  IPHC compression efficiency is *based* on the
idea that redundant information appears in both the L2 and L3 (IPv6) header
address fields and may be elided from the latter.

Having said that, some link technologies (e.g. 802.15.4) allow for
dynamically
assigned short-form identifiers assigned by a local coordinator.  Greater
IPHC compression efficiency is realized in this case.  In terms of your
concerns, short L2 addresses may make address scanning easier but
mitigate node tracking (since a device will get a different identifier when
it
changes networks) and device-specific attacks (since OUI is absent).

In general, we need to distinguish between L2 addresses (which may be
dynamic) and "hardware" addresses (which I take to mean EUI-64 or
Modified EUI-64 Format addresses formed from MAC-48 addresses).

> It was raised by Carsten in 6lo that we have to be more specific regarding
the use of the term "hardware address".  To discuss one 6lo proposal with
which I am intimately familiar (draft-ietf-6lo-6lobac), MS/TP master nodes
effectively have a 7-bit hardware address.  This is right-justified in a
field
of zeros to create a 16-bit short-form identifier, which is then converted
to
a 64-bit Modified EUI-64 Format IID (just as in RFC 4944).  Why?  It's
designed
to work with IPHC.  My point is that not all hardware addresses are EUI-64s
and not all L2 address are hardware addresses, so let's be more precise in
our
language and in our recommendations.

> It's actually trading cost for security and privacy.  Legacy technologies
like
MS/TP are designed to run on any micro-controller that has a UART, a 5 ms
resolution timer, and an RS-485 driver.  These technologies compete in very
cost-sensitive markets.  The system designer is making a conscious decision
to place security features elsewhere, e.g. in gateways. If privacy is a
concern
they can specify a more capable processor, more memory, and a different link
technology - but only of the customers will pay for it.

> As long as it remains RECOMMENDED and not a SHALL, I have no major
issue (implementers may follow the recommendation, or not, according to
their particular threat analyses).

Regards, Kerry

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 12 Nov 2014 19:49:22 -0500

On Tue, Nov 11, 2014 at 3:13 PM, Dave Thaler <[email-masked]> wrote:

> Hi Dave,

I'd like to understand your position more precisely.  One possible
interpretation is that
you advocate a "one size fits all" solution that constrained nodes MUST
implement
whether or not privacy is required in a given deployment.  If you actually
mean that
something like RFC 7217 is mandatory-to-implement, then I think that
effectively
changes SHOULDs and RECOMMENDEDs to SHALLs and runs counter to the
consensus that was reached previously.

Much depends on a precise definition of "a mechanism that provides
privacy".  If this
means opaque IIDs with 64 bits of entropy, then that drastically reduces
the efficiency
of IPHC [RFC 6282] for any 6lo deployment that is not using 64-bit L2
addresses.  In
the event, the 64-bit source and destination IIDs must be included in the
IPHC header
adding an additional 16 bytes to each packet.  This is costly in terms of
both latency
and bandwidth in constrained networks.

OTOH, if your definition of privacy can be satisfied by IIDs formed from
smaller
(perhaps locally assigned) L2 identifiers, then I might be less opposed to
your
position.  RFC 6282 was designed initially to work with 16- and 64-bit
802.15.4
addressing modes.  However, all current 6lo proposals have specified IPHC as
mandatory-to-implement.  Technologies with L2 addresses less than 16 bits in
length are left-padded with zeros to 16 bits and passed to the IPHC
compressor.

I think the net effect of IIDs generated from small L2 addresses is that
corresponding
networks may be more susceptible to address scanning.  However, this seems
like
something that might possibly be mitigated by the border gateway.  Node
tracking
is a non-issue since short identifiers are typically assigned by a local
coordinator at
enrollment.  (Whether or not a local identifier remains stable over time
per device,
per network could be a local policy decision.)  Similarly, device-specific
attacks are a
non-issue because the short identifier contains no OUI (it is effectively
opaque).

I think the proposed recommendation [draft-ietf-6man-default-iids] must be
considered
in terms of how it impacts IPHC [RFC 6282].  The bulk of IPHC's efficiency
is based
on deriving IIDs from the encapsulating header.  Simply generating opaque
64-bit
L2 addresses will only work for technologies like 802.15.4 that support
those addresses.
Other 6lo technologies MUST be allowed to generate IIDs from small
identifiers and
realize the benefits of IPHC.  That may make them unsuitable for
deployments that
require maximum privacy.

Regards, Kerry

-Dave
> the
> generated for
> that
> suggested -

---

From: Dave Thaler <[email-masked]>
Date: Thu, 13 Nov 2014 05:04:38 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kerry Lynn
Sent: Wednesday, November 12, 2014 2:49 PM
To: Dave Thaler
Cc: Fernando Gont; Ralph Droms (rdroms); 6man WG; [email-masked]
Subject: Re: Comments on draft-ietf-6man-default-iids-01.txt

On Tue, Nov 11, 2014 at 3:13 PM, Dave Thaler <[email-masked]<mailto:[email-masked]>> wrote:

I'd like to understand your position more precisely.  One possible interpretation is that
you advocate a "one size fits all" solution that constrained nodes MUST implement
whether or not privacy is required in a given deployment.  If you actually mean that
something like RFC 7217 is mandatory-to-implement, then I think that effectively
changes SHOULDs and RECOMMENDEDs to SHALLs and runs counter to the
consensus that was reached previously.

[DT] No.  I specifically said “*a* mechanism” rather than “RFC 7217” for the MUST.

Much depends on a precise definition of "a mechanism that provides privacy".  If this
means opaque IIDs with 64 bits of entropy, then that drastically reduces the efficiency
of IPHC [RFC 6282] for any 6lo deployment that is not using 64-bit L2 addresses.  In
the event, the 64-bit source and destination IIDs must be included in the IPHC header
adding an additional 16 bytes to each packet.  This is costly in terms of both latency
and bandwidth in constrained networks.

[DT] No, I didn’t say “opaque IIDs with 64 bits of entropy” either.  I said one that
mitigates the privacy threats (opaque IIDs with 64 bits of entropy can certainly meet that, but I
distinguish between requirement and specific solutions).  And FWIW, I disagree that there is any
efficiency reduction in data packets that is inherently required (some HC mechanisms compress
out the addresses entirely and just a flow id of some sort).   There may be work needed, but
privacy does not inherently require any more bytes in data packets.

OTOH, if your definition of privacy can be satisfied by IIDs formed from smaller
(perhaps locally assigned) L2 identifiers, then I might be less opposed to your
position.  RFC 6282 was designed initially to work with 16- and 64-bit 802.15.4
addressing modes.  However, all current 6lo proposals have specified IPHC as
mandatory-to-implement.  Technologies with L2 addresses less than 16 bits in
length are left-padded with zeros to 16 bits and passed to the IPHC compressor.

[DT] I think the discussion of number of bits in the IID is sort of a red herring.

I think the net effect of IIDs generated from small L2 addresses is that corresponding
networks may be more susceptible to address scanning.  However, this seems like
something that might possibly be mitigated by the border gateway.  Node tracking
is a non-issue since short identifiers are typically assigned by a local coordinator at
enrollment.  (Whether or not a local identifier remains stable over time per device,
per network could be a local policy decision.)  Similarly, device-specific attacks are a
non-issue because the short identifier contains no OUI (it is effectively opaque).

I think the proposed recommendation [draft-ietf-6man-default-iids] must be considered
in terms of how it impacts IPHC [RFC 6282].  The bulk of IPHC's efficiency is based
on deriving IIDs from the encapsulating header.  Simply generating opaque 64-bit
L2 addresses will only work for technologies like 802.15.4 that support those addresses.
Other 6lo technologies MUST be allowed to generate IIDs from small identifiers and
realize the benefits of IPHC.  That may make them unsuitable for deployments that
require maximum privacy.

[DT] I haven’t read RFC 6282, but I can easily imagine that it might (I don’t know)
need updates in order to meet privacy requirements.

-Dave

Regards, Kerry

-Dave

> From: ipv6 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Fernando Gont
> Cc: [email-masked]<mailto:[email-masked]>
> e-mail: [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Wed, 12 Nov 2014 22:31:51 -1000

Hi, Kerry,

On 11/11/2014 12:25 PM, Kerry Lynn wrote:
> 
> On Mon, Nov 10, 2014 at 10:45 PM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

Exactly. And what I'm saying is that, architecturally speaking, there's
not much of reason for expecting that to be the case. e.g., if the
devices get their addresses via DHCPv6 as opposed to SLAAC, the HC will
fail. --  of course, this is off-topic for this specific discussion.

> mitigate node tracking (since a device will get a different identifier
> when it

Do these technologies employ such identifiers for the same purpose as a
MAC address?

> the use of the term "hardware address".

link-layer addresses?

If not, please send text.

Thanks!

Cheers,

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 13 Nov 2014 09:37:55 -1000

> Modified EUI-64 Format addresses formed from MAC-48 addresses).

That was my point at the microphone:

We need terms here that people who work on link layers and adaptation layers (which together create the subnetwork layer) can understand.
“Hardware address” is not such a term, because it means too many things to different people.
If we mean “high-entropy stable identifier, with a lifetime association to a device, that discloses vendor information”, we should say just that (maybe with a shorter word).

So, first, we need terms that work.

Second, we need to be explicit about the objectives, and discuss them separately.  
They may have different priorities in different areas of application.

Then, we need to make the solution choices a bit more realistic.  There isn’t a binary choice here (conform to solution X or don’t).
Instead, there are many solution options, each of which can satisfy some objectives and doesn’t satisfy others.

Any MUSTs in this document must be about attaining (some of) the objectives, not about one specific method aimed at getting there.

RFC 3819 may be a useful model for how to deliver advice for Internet Subnetwork Designers (the present one doesn’t have to take five years to publish, though).

Grüße, Carsten

---

From: Fernando Gont <[email-masked]>
Date: Thu, 13 Nov 2014 09:52:49 -1000

Hi, Carsten,

On 11/13/2014 09:37 AM, Carsten Bormann wrote:
>> In general, we need to distinguish between L2 addresses (which may
>> be dynamic) and "hardware" addresses (which I take to mean EUI-64
>> or Modified EUI-64 Format addresses formed from MAC-48 addresses).
> 
> We need terms here that people who work on link layers and adaptation
> layers (which together create the subnetwork layer) can understand. 
> “Hardware address” is not such a term, because it means too many
> things to different people. If we mean “high-entropy stable
> identifier, with a lifetime association to a device, that discloses
> vendor information”, we should say just that (maybe with a shorter
> word).

mmm.. not really. We problably mean something like "link-layer
addresses" (referring to an identifier that is employed to address
packets at such layer, without inferring any sort of properties on them).

> Second, we need to be explicit about the objectives, and discuss them
> separately. They may have different priorities in different areas of
> application.
> 
> Then, we need to make the solution choices a bit more realistic.
> There isn’t a binary choice here (conform to solution X or don’t). 
> Instead, there are many solution options, each of which can satisfy
> some objectives and doesn’t satisfy others.

We're addressing the general case here. For other cases, the plan is to
say that those technologies that don't follow the SHOULD, MUST implement
*some* privacy-enhanced IIDs (and it should be configurable whether to
use them or not) -- please check Dave Thaler's email.

> Any MUSTs in this document must be about attaining (some of) the
> objectives, not about one specific method aimed at getting there.

As noted, the only "MUST" will be the one I've described above. -- but
such "MUST" is not yet in the I-D.

Thanks!

Cheers,

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 13 Nov 2014 18:38:53 -0500

On Thu, Nov 13, 2014 at 12:04 AM, Dave Thaler <[email-masked]> wrote:

>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Kerry
> Lynn
> *Sent:* Wednesday, November 12, 2014 2:49 PM
> *To:* Dave Thaler
> *Cc:* Fernando Gont; Ralph Droms (rdroms); 6man WG;
> [email-masked]
> *Subject:* Re: Comments on draft-ietf-6man-default-iids-01.txt
>
>
>
[KL] With my implementer's hat on, how do I know whether a given mechanism
"provides privacy"?  This is probably cluelessness on my part, but are the
requirements spelled out somewhere?  I imagine the requirements follow from
a threat model?  Are we assuming the same threat model for all hosts?

> privacy does not inherently require any more bytes in data packets.
RFC 6282 defines a method for deriving IIDs from the source and/or
destination
addresses in the encapsulation header.  Unicast IPv6 addresses may be
compressed
to 64, 16, or 0 bits in the encoded IPv6 header.

Let's say the goal is to elide the IIDs.  In the case that seems to have
everyone worried,
the encapsulation header is 802.15.4 and the source and destination
addresses are
EUI-64s.  In this case, one cannot simply use the L2 source and destination
addresses
as IIDs since this apparently does not provide privacy.  Therefore, IIDs
must be carried
in the L3 header - increasing the size of the packet (because the IIDs
cannot be elided).

An alternative that was discussed in 6lo would be to generate a random
locally assigned
L2 address that provides privacy.  In the event, this value can be used as
an IID and
this does not expand the packet.

What no one has been able to answer for me to this point is whether (in the
case of
802.15.4) an IID generated from a locally assigned 16-bit L2 address per
RFC 6282
section 3.2.2 meets the standard of "provides privacy".

> [DT] I think the discussion of number of bits in the IID is sort of a red
Not if one of the requirements is to mitigate address scanning.  The size
of the search
space depends on the entropy in the IID.  I can imagine an adversary using
statisical
methods to determine the size of the L2 address space and thereby making
some
inference regarding the underlying technology on a given link.

> need updates in order to meet privacy requirements.
Again, please point me at them.

Thanks, Kerry

---

From: Fernando Gont <[email-masked]>
Date: Thu, 13 Nov 2014 14:08:33 -1000

Hi, Kerry,

On 11/13/2014 01:38 PM, Kerry Lynn wrote:
>     __ __
> 
>     [DT] No.  I specifically said “*a* mechanism” rather than “RFC 7217”
>     for the MUST.____
> 
>     __ 
> 
> "provides privacy"? 

The relevant wg (which decides not to follow this recommendation) should
generate a proposal that does.

> This is probably cluelessness on my part, but are the

see the address-generation-privacy I-D.

> EUI-64s.  In this case, one cannot simply use the L2 source and
> destination addresses

Essentially the goals are that:

* the node cannot be tracked
* the IID does not leak device information (e.g., manufacturer)
* the resulting addresses do not result in patterns (which would make
address scans trivial)

> L2 address that provides privacy.  In the event, this value can be used
> as an IID and
> What no one has been able to answer for me to this point is whether (in
> the case of

It probably does.. but it still makes address scans trivial.

> Not if one of the requirements is to mitigate address scanning.  The
> size of the search
> space depends on the entropy in the IID.  I can imagine an adversary
> using statisical

Not that they have used statistical methods, but please check
draft-ietf-opsec-ipv6-host-scanning

Thanks,

---

From: Dave Thaler <[email-masked]>
Date: Fri, 14 Nov 2014 00:24:22 +0000

> a threat model?  Are we assuming the same threat model for all hosts?

Yes (at least for all that have Internet connectivity).
See RFC 6973, especially section 5.  And some further discussion in 
https://tools.ietf.org/html/draft-ietf-6man-ipv6-address-generation-privacy
especially section 3.

> RFC 6282 defines a method for deriving IIDs from the source and/or destination
> addresses in the encapsulation header.  Unicast IPv6 addresses may be compressed

0 bits is good in this case.

> Let's say the goal is to elide the IIDs.  In the case that seems to have everyone worried,
> the encapsulation header is 802.15.4 and the source and destination addresses are
> EUI-64s.  In this case, one cannot simply use the L2 source and destination addresses
> as IIDs since this apparently does not provide privacy.  Therefore, IIDs must be carried
> in the L3 header - increasing the size of the packet (because the IIDs cannot be elided).

No, the L3 header (as such) does not have to appear in the data packet.  That's what
header compression is for.  As you mentioned, there may be 0 bits of the address in
the packet, so obviously IIDs need not be carried in each data packet.

> An alternative that was discussed in 6lo would be to generate a random locally assigned
> L2 address that provides privacy.  In the event, this value can be used as an IID and

Certainly the stable per-network random ID generation mechanism could be at layer 2
and that essentially becomes another variant way to implement 
[I-D.ietf-6man-stable-privacy-addresses] if it's 64 bits of entropy.

However, either way it doesn't expand the packet if there's 0 address bits in the packet.

> What no one has been able to answer for me to this point is whether (in the case of
> 802.15.4) an IID generated from a locally assigned 16-bit L2 address per RFC 6282

See the discussion of "anonymity set" in RFC 6973.

> [DT] I think the discussion of number of bits in the IID is sort of a red herring.
 > 
> Not if one of the requirements is to mitigate address scanning.  The size of the search
> space depends on the entropy in the IID.  I can imagine an adversary using statisical
> methods to determine the size of the L2 address space and thereby making some

Ah, good point, that is true.   Using only 16 bits of entropy on a subnet does
not mitigate address scanning.  So yes my opinion that each link layer technology
MUST have a way to use much more bits of entropy in address generation,
MAY have a way to use fewer, and SHOULD be configurable if so.
 
> networks may be more susceptible to address scanning.

Yes.

> However, this seems like
> something that might possibly be mitigated by the border gateway.

Not entirely, no.  Addresses leak out via various mechanisms, it's not just about incoming packets.

> in terms of how it impacts IPHC [RFC 6282]. 

And similarly RFC 6282 needs to be evaluated in terms of whether it adequately meets
the requirements or requires revision.  (So far I haven't heard a reason it's insufficient,
so I'm not saying it is, especially if 0 bits of the address can appear in the packet,
then it should be possible to use any address whatsoever, based on context info.)

> Again, please point me at them.

Again, start with RFC 6973 section 5, and then additional discussion in 
https://tools.ietf.org/html/draft-ietf-6man-ipv6-address-generation-privacy
section 3.

-Dave

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 13 Nov 2014 19:30:52 -0500

On Thu, Nov 13, 2014 at 2:52 PM, Fernando Gont <[email-masked]>
wrote:

> [KL]  What about locally administered link-layer addresses?  Are you
concerned about *any* re-use of L2 addresses at L3, whether they are
"opaque" or not?

> Can you point me at the requirements that privacy-enhanced IIDs must
satisfy?
If, in the limit, it requires no CPU cycles, memory, or bandwidth to
implement
then I might not object to the MUST.

Kerry

---

From: Glen Turner <[email-masked]>
Date: Sun, 16 Nov 2014 11:46:32 +1030

draft-ietf-6man-default-iids-01 says
> nodes SHOULD NOT generate Interface Identifiers with the schemes
> specified in … [RFC5072].

I took a half hour to read this draft. It struck me that there was a long list of RFCs being modified. So I selected one RFC (the last in the list) for a closer look to see if there was any resulting underspecification.

IPv6 over PPP in RFC5072 can assign IPv6 interface identifiers in three ways:

1) Section 4.1: a configuration option from the partner; IID selected by host from EUI-64.

2) Section 4.1: a configuration option from the partner; IID selected by host from "good random" source.

3) Section 4.1: a configuration option from the partner value 0; IID selected by the partner, mechanism unknown.

The intent of draft-ietf-6man-default-iids is clearly to remove option (1) and update options (2) and (3) to the use much the same algorithm as in RFC7217. But it cannot use exactly the same algorithm, as IPv6 concepts such as DAD (and thus RFC7217's DAD_Counter) are not yet available to this link-layer protocol.

Thus draft-ietf-6man-default-iids alters RFC5072 in underspecified ways.

Reading further, the assignment of Interface ID via the link layer makes DAD pointless

  "As long as the interface identifier is negotiated in the IPV6CP phase
   of the PPP connection setup, it is redundant to perform duplicate
   address detection (DAD) as a part of the IPv6 Stateless Address
   Autoconfiguration protocol [3] on the IPv6 link-local address
   generated by the PPP peer.  It may also be redundant to perform DAD
   on any global unicast addresses… [subject to some conditions]"

It is arguable that RFC7217 is incorrect for PPP: DAD should not be run, and if it is run and a DAD conflict occurs a new address should not be attempted but the link terminated due to the link layer configuration error.

In any case, applying RFC7217 to RFC5072 clearly leads to a underspecified protocol, with possible inefficiency and possibly interworking issues with differing but reasonable readings of the combined specifications.

Given the issues with one randomly chosen link-layer RFC, can I suggest that this ID review the application of RFC5072 to each of the listed link-layer protocols, and give details to resolve any under-specification or ambiguities which are discovered?

I hope this suggestion is helpful and results in a better specification.

-glen

---

From: Michael Richardson <[email-masked]>
Date: Sun, 16 Nov 2014 02:16:37 -0500

Thank you so much for having done this analysis; I hadn't even begun to think
how this might apply to PPP(oE) links. I am in charge of adding v6 to a PPP
access gateway.

    > I took a half hour to read this draft. It struck me that there was a
    > long list of RFCs being modified. So I selected one RFC (the last in
    > the list) for a closer look to see if there was any resulting
    > underspecification.

    > 3) Section 4.1: a configuration option from the partner value 0; IID
    > selected by the partner, mechanism unknown.

    > The intent of draft-ietf-6man-default-iids is clearly to remove option
    > (1) and update options (2) and (3) to the use much the same algorithm
    > as in RFC7217. But it cannot use exactly the same algorithm, as IPv6

Do you think that this should apply to the ACS/LNS/gateway side of the PPP
connections?   

I agree that an end-host system SHOULD use a privacy address for their end of
the PPP link, but in the case where it's a CPE router, it isn't even always
useful or interesting to number the PPP link with other than link layer
addresses.   If the CPE answers things like traceroute (i.e. ICMPs) with an
address taken from another interface (or from a loopback numbered with the
DHCPv6PD-delegated prefix), then the link address probably never appears
anywhere.

I wish that I had a data set to say what current CPEs do.  OpenWRT seems to
basically do (2) already.  The other devices I tested with just crashed when
I offered them IPv6 via PPPoE :-(

Yes.

I personally think generating non-private IIDs to non-moveable equipment
(e.g. CPEs) in the home it silly: the devices are entirely identifiable from
the delegated prefix, assuming that doesn't change.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Ole Troan <[email-masked]>
Date: Mon, 17 Nov 2014 13:07:24 -0800

Glen,

> The intent of draft-ietf-6man-default-iids is clearly to remove option (1) and update options (2) and (3) to the use much the same algorithm as in RFC7217. But it cannot use exactly the same algori…

DAD works over a PPP link like any other multicast capable link-layer.
the interface-identifier uses for a global unicast address may very well be different from the one negotiated with IPv6CP (which should be used for generating the link-local address).

> It is arguable that RFC7217 is incorrect for PPP: DAD should not be run, and if it is run and a DAD conflict occurs a new address should not be attempted but the link terminated due to the link lay…

I think that's a misunderstanding. a peer on a PPP link may use may different interface-ids on the link, and DAD may only be omitted for the one negotiated with IPv6CP.

> I hope this suggestion is helpful and results in a better specification.

you have to do a RS/RA exchange on PPP as well, and I think there are implementations that also do the equivalent of address resolution, although that's not strictly necessary.

as far as I can see IPv6 over PPP is no different that IPv6 over any other multicast capable link-layer.

cheers,
Ole

---

From: Ralph Droms <[email-masked]>
Date: Fri, 21 Nov 2014 10:16:43 -1000

On Nov 17, 2014, at 11:07 AM 11/17/14, Ole Troan <[email-masked]> wrote:

> [...]

Ole - In your opinion, does draft-ietf-6man-default-iids-01.txt give enough detail as written to be applied as an update to RFC 5072?

- Ralph

---

From: Ole Troan <[email-masked]>
Date: Mon, 24 Nov 2014 12:34:40 +0100

Ralph,

> Ole - In your opinion, does draft-ietf-6man-default-iids-01.txt give enough detail as written to be applied as an update to RFC 5072?

I don't know. I think we need to wait for an update of the draft with the changes discussed at the meeting.

then we need to look at the set of IPv6 over foo documents and decide if and what updates are required.

cheers,
Ole

---

From: Ralph Droms <[email-masked]>
Date: Mon, 24 Nov 2014 14:01:13 -0500

> then we need to look at the set of IPv6 over foo documents and decide if and what updates are required.

I agree and was about to bring this point up myself.

- Ralph

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Nov 2014 08:09:29 +1300

> then we need to look at the set of IPv6 over foo documents and decide if and what updates are required.

As a reminder, we already attempted to catalogue those documents in
http://tools.ietf.org/html/draft-ietf-6man-why64-08#section-4.1 ,
paragraph 3. We found 14 RFCs and 4 drafts.

   Brian

---

From: Ralph Droms <[email-masked]>
Date: Mon, 24 Nov 2014 14:39:05 -0500

> paragraph 3. We found 14 RFCs and 4 drafts.

Looks like there is pretty good overlap between the list of IPv6-over-foo documents in draft-ietf-6man-why64 and the list of RFCs updated by draft-ietf-6man-default-iids.  Authors of the two documents might want to coordinate their lists (I understand the lists won't necessarily match exactly).

These two documents listed in draft-ietf-6man-why64 - draft-brandt-6man-lowpanz-02 and draft-ietf-6man-6lobac-01 - have moved to 6lo, draft-ietf-6lo-lowpanz-08 and draft-ietf-6lo-6lobac-00, respectively.

If draft-ietf-6man-default-iids is published as an RFC, I assume documents published after that publication will be updated to reflect its requirements and we'll want to manage those affected drafts that are in process to make sure they coordinate with draft-ietf-6man-default-iids.

- Ralph

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Nov 2014 15:21:28 +0100

Le 24/11/2014 20:39, Ralph Droms a écrit :
>>>>> [...] as far as I can see IPv6 over PPP is no different that
>>>>> IPv6 over any other multicast capable link-layer.
>>>> Ole - In your opinion, does draft-ietf-6man-default-iids-01.txt
>>>> give enough detail as written to be applied as an update to RFC
>>>> 5072?
>>>
>>> I don't know. I think we need to wait for an update of the draft
>>> with the changes discussed at the meeting.
>>>
>> As a reminder, we already attempted to catalogue those documents
>> in http://tools.ietf.org/html/draft-ietf-6man-why64-08#section-4.1
>> , paragraph 3. We found 14 RFCs and 4 drafts.
>
> Looks like there is pretty good overlap between the list of
> IPv6-over-foo documents in draft-ietf-6man-why64 and the list of RFCs
> updated by draft-ietf-6man-default-iids.  Authors of the two
> documents might want to coordinate their lists (I understand the
> lists won't necessarily match exactly).

Right, the why64 list does not contain 2491 NBMA, 3572 MAPOS, 4391 
Infiniband cited by the default-iids; the list in this latter does not 
cite 4944 802.15.4, 2529 6over4, 5214 ISATAP cited by why64.

I didnt know IPv6-over-MAPOS and -Infiniband existed.  I wonder to what 
extent are they or have they been used.

> These two documents listed in draft-ietf-6man-why64 -
> draft-brandt-6man-lowpanz-02 and draft-ietf-6man-6lobac-01 - have
> moved to 6lo, draft-ietf-6lo-lowpanz-08 and draft-ietf-6lo-6lobac-00,
> respectively.
>
> If draft-ietf-6man-default-iids is published as an RFC, I assume
> documents published after that publication will be updated to reflect
> its requirements and we'll want to manage those affected drafts that
> are in process to make sure they coordinate with
> draft-ietf-6man-default-iids.

I agree.  Similarly, recommendation in default-iids mayneed to influence 
a number of _individual proposal_ drafts IPv6-over-foo like 
draft-hong-6lo-ipv6-over-nfc-02 or draft-petrescu-ipv6-over-80211p-02.

Alex

> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Fernando Gont <[email-masked]>
Date: Tue, 25 Nov 2014 17:29:32 -0300

Hi, Ralph,

> Ole - In your opinion, does draft-ietf-6man-default-iids-01.txt give enough detail as written to be applied as an update to RFC 5072?

mmm.. what's missing?

The idea seems to be simple: I you need to generate an IID, use the
scheme in RFC7217.

Or were you thinking about something along the lines of:

o<---o<---o<---o<---o<---o<---o<---o<---o<---

The following text from Section X of RFC5072:

   [Text from RFC5072]

is formally replaced with:

   [Text from our ID]
o<---o<---o<---o<---o<---o<---o<---o<---o<---

?

I really doubt such approach would buy as any additional clarity -- but
it would rather include unnecessary text, duplicate text from our ID,
and also possibly make look our ID rather ugly :-) (with so much "copy &
paste").

Thoughts?

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Nov 2014 10:39:47 +1300

On 26/11/2014 03:21, Alexandru Petrescu wrote:
...
>>> , paragraph 3. We found 14 RFCs and 4 drafts.
...
> Infiniband cited by the default-iids; 

We tried to find all the ones that explicitly mentioned the 64 bit
length. I guess we (well, some grep script) missed these three.

The text in why64 currently says "These documents include..." so
it is not wrong. However, if people think it's useful and the WG Chairs
and AD agree, we can ask the RFC Editor to add three more during AUTH48.

   Brian

P.S. I am surprised to discover that nobody ever defined IPv6 over HIPPI,
considering that HIPPI was the main argument for Jumbograms in the first place.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 25 Nov 2014 21:54:45 +0000

Hi Brian,

> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Tuesday, November 25, 2014 1:40 PM
> To: Alexandru Petrescu
> Cc: [email-masked]
> Subject: Missing references in the why64 draft [was Comments on draft-ietf-6man-default-iids-01.txt]
> 

The normative references for IPv4 (RFCs 2834, 2835) peg the MTU at just under
64KB which is of course the maximum IPv4 packet size. My understanding was
that the original HIPPI (HIPPI-800) was limited to 64KB at the link layer as well,
but  I'm not sure if the same was true for HIPPI-6400.

The people who were with me at NASA Ames during the mid-90's may know
more about this.

Thanks - Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 25 Nov 2014 22:21:24 +0000

> From: ipv6 [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Tuesday, November 25, 2014 1:55 PM
> To: Brian E Carpenter; Alexandru Petrescu
> Cc: [email-masked]
> Subject: RE: Missing references in the why64 draft [was Comments on draft-ietf-6man-default-iids-01.txt]
> 
> Hi Brian,
> 

Dang, that's not quite right. The original HIPPI spec (RFC2067) says:

   "HIPPI has no inherent limit on packet size.  The HIPPI-FP header
   contains a 32 bit D2_Size field that, while it may limit packets to
   about 4 gigabytes, imposes no practical limit for networking
   purposes.  Even so, a HIPPI-SC switch used as a LAN needs an MTU so
   that Destination buffer sizes can be determined.

   The MTU for HIPPI-SC LANs is 65280 bytes."

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Nov 2014 10:55:21 +1300

I just discovered draft-hong-6lo-ipv6-over-nfc, which also
assumes /64. Not sure it's worth adding, because our point is
already clear: *everybody* assumes /64.

    Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Nov 2014 11:25:14 +0100

> already clear: *everybody* assumes /64.

I agree, not worth adding at this time, especially since it's simply an 
individual proposal in the 6lo WG.

Everybody seem to assume /64 when writing IPv6-over-foo documents.  It's 
not just being forced into it by IEEE specs (NFC and PPP are not IEEE), 
it's imitating IPv6/Ethernet in the hope to reach same success.

This is a fallacy (imitate Ethernet) because the links are so different 
in nature: a brief req/response to an NFC card, as is the flashing of a 
QR code, can't really qualify as 'links' like an Ethernet.  IPv6 should 
run on them, but they're different.

Alex

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sat, 29 Nov 2014 01:19:04 +0000 (UTC)

----- Original Message -----
> From: Alexandru Petrescu <[email-masked]>
> To: [email-masked]
> Cc: 
> Sent: Friday, 28 November 2014, 21:25
> Subject: Re: Missing references in the why64 draft [was Comments on draft-ietf-6man-default-iids-01.txt]
> 

I also agree. The only related thought I had was that it might be worth pointing out that the existence of current drafts that are making this assumption is evidence that this is and is likely to be a continuing assumption.

>>>>>>  in 
> http://tools.ietf.org/html/draft-ietf-6man-why64-08#section-4.1