Subject: Review of draft-ietf-6man-rfc4291bis-03

From: Tim Chown <[email-masked]>
Date: Mon, 18 Jul 2016 16:23:40 +0000

Hi again,

Ole asked me to review draft-ietf-6man-rfc4291bis-03 as well.

This document also appears to be close to being ready. It seems to meet the criteria of RFC6410 as a candidate for advancement to IS.

A general question exists as per the other two -bis documents as to whether new material that’s incorporated should include references for the RFCs the updates draw from. Again, that seems a little inconsistent in this document. Two other general questions are whether ULAs should be explicitly called out here (as a replacement for site-locals), and whether we should add IANA registry pointers in the IANA section (no action for IANA, but a reader will then know which registries are in use).  There is no mention of ULAs in the change log, so it’s not clear if it’s been discussed and rejected, or not.

General comments:

Section 2:

p. 7 it looks like the new Section 2.2.3 takes text/content from RFC5952, but does not cite it. Should it? 

p.9 and p.10 - is there a requirement to add a reference to RFC4193 for ULAs here? They are defined at Global scope, but have a specific binary prefix that could be added to the table on p.9. While treated in principle by applications as Global scope addresses, their handling/use can differ, e.g. through RFC6724-based address selection.  That said, I note that RFC4193 does not say it formally updates RFC4192.

p.11 pragmatically, should there be a mention of RFC7421 (Why /64?) at the end of Section 2.4?  Because assumptions *are* now made about the 64-bit boundary 10 years on from the original publication of 4291.

p.11 this section on IIDs adds references to RFC7721 (security & privacy considerations) and RFC7217 (stable privacy IIDs), but doesn’t differentiate between “temporary" addresses (as per RFC4941) and regular addresses. Should it?

p.11 there is no reason given here for the IEEE MAC derived IIDs being no longer recommended. This could be written to be more clearly integrated with the reference to RFC7721 above.

p.14 again, should the site-local section be replaced with ULAs?

p.16 there is no reference to RFC7371 (multicast address architecture update) or RFC7346 (multicast scopes); should these be added?

p.16 it seems that RFC7371 changes were backed out in the -02 version of this bis document, on the grounds that implementations hadn’t changed to reflect this.  This surprised me, but I assume this was discussed and there is WG consensus to do this? 

p.17 a good chunk of this page is copied from RFC7346, without citing it.

Section 3 (IANA):

p.21 there is no mention of RFC5453, which created the IANA registry for reserved IPv6 interface identifiers. Should there be?

p.21  there is no mention of the IANA IPv6 Special-Purpose Address Registry, as per RFC6890. Should there be?

p.21 should Section 6 of RFC7346 be captured here?

Appendix A

p.24 RFC7136 talks about the (lack of) meaning in IID bits, esp. related to the u,g bits. Do we need to refer to this in Appendix A, where IEEE MAC-based IIDs are discussed? Or is this not important given we’re not recommending this form of IID generation any more?

Other comments:

RFC6052 on IPv6 Addressing of IPv4/IPv6 Translators states it formally updates RFC4291.  It reserves 64:ff9b::/96 as a well-known prefix. Though it then also says in the text that no updates to RFC4291 are required. Do we need to change anything in 4291bis on account of RFC6052 or not?

Tim

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Jul 2016 10:57:55 +0200

Hi,

I would suggest to consider that it is on _wifi_ that there are more IP
address privacy concerns, rather than on Ethernet RFC2464.

I suspect that RFC2464 Ethernet Frame Format is not what gets on the
wireless.  On wireless we see 802.11 Data Headers not EthernetII
headers.  A conversion between these two headers happens in each
computer, yes.

The problem is that there is no RFC "IPv6-over-wifi" to patch.  It would
be in that fictitious document that the solution to privacy worries -
e.g. random MAC or random IID - would be expressed.

That is why I am saying that there is need of advice of what to put in a
potential "IPv6-over-80211" new document.

Alex
PS: this also applies to IPv6-over-cellular networks using RFC2464
     inside the computer but obviously not on the network.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Jul 2016 21:29:45 +1200

On 19/07/2016 20:57, Alexandre Petrescu wrote:
> The problem is that there is no RFC "IPv6-over-wifi" to patch.

There's a reason for that: above the driver, the IP layer doesn't
see *any* differences between 802.11 and any form of 802.3. So the RFC
for 802.11 is RFC2464. Privacy issues arose first for wired broadcast
networks - in 1983, Ethernet on yellow co-axial cables was wide open
to eavesdroppers.

> It would

Disagree. The issue may be more acute for wireless but it also applies
to 802.3. At the level of IID formation or MAC address randomization,
I don't think the technology matters - assume that eavesdropping is always
possible.

   Brian

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Jul 2016 11:49:29 +0200

Le 19/07/2016 à 11:29, Brian E Carpenter a écrit :
>> I would suggest to consider that it is on _wifi_ that there are
>> more IP address privacy concerns, rather than on Ethernet RFC2464.
>>
>> I suspect that RFC2464 Ethernet Frame Format is not what gets on
>> the wireless.  On wireless we see 802.11 Data Headers not
>> EthernetII headers.  A conversion between these two headers
>> happens in each computer, yes.
>>
> see *any* differences between 802.11 and any form of 802.3.

I agree.  But I think it should.

There are many differences between 802.11 WiFi and Ethernet that should
be reckoned: MTU size, QoS parameters, and more.

> So the RFC for 802.11 is RFC2464. Privacy issues arose first for
> wired broadcast networks - in 1983, Ethernet on yellow co-axial
> cables was wide open to eavesdroppers.

I can agree.

I meant that WiFi is easier to listening the media unnoticed rather than
cutting or plugging wires which is more noticeable.

This translates into some implemented mechanisms of protection privacy
which involve 802.11-specific parameters like ESSID - MAC address
generators.

Such description can not be in an RFC2464 update because Ethernet does
not have ESSID, MSISDN on cellular, or similar.

>> It would be in that fictitious document that the solution to
>> privacy worries - e.g. random MAC or random IID - would be
>> expressed.
>>
>> That is why I am saying that there is need of advice of what to
>> put in a potential "IPv6-over-80211" new document.
>
> Disagree. The issue may be more acute for wireless but it also
> applies to 802.3. At the level of IID formation or MAC address
> randomization, I don't think the technology matters - assume that
> eavesdropping is always possible.

I can agree.  But the protection is different on different media.

On 802.3 the privacy protection mechanisms may be different than on 802.11.

Alex

>
> Brian
>
>>
>> Alex PS: this also applies to IPv6-over-cellular networks using
>> RFC2464 inside the computer but obviously not on the network.
>>
>> [email-masked] Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6
>  IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Francis Dupont <[email-masked]>
Date: Tue, 19 Jul 2016 11:57:59 +0200

I have another kind of counter-argument: if we publish
an IPv6-over-80211 document, it should specify the real MTU
of 802.11 which is not 1500 but larger. As in the real world
everybody without significant exceptions clearly ignore that
and use only 1500 MTU there is no need at all for a specific
document (vs reusing the 802.3 one).

Regards

[email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Jul 2016 18:22:43 +0200

> document (vs reusing the 802.3 one).

I would like to at least identify this number.  One some other list 
someone says 2308 bytes, but is that specified somewhere?

As for the counter-argument: I tend to agree that one should be careful 
not to break existing computers having MTU 1500bytes forever.  To 
address part of that the PMTUD mechanism was designed, I think.

Alex