Re: [v6ops] Update of RFC 7084 -- Re: Slides from AWS, SAP, ESnet, Dell in side meeting and call for volunteers on 3 research topics

[Ted Lemon <[e-mail]>]

As a counterpoint to this (my opinion on this is a bit orthogonal), Roman
Danyliw’s discuss on draft-ietf-dnssd-srp asked why we didn’t mention an
ipv4 equivalent to 7084, to which my answer was “it actually covers ipv4
adequately.”

Personally I think that we should decide what to recommend if we specify
IPv4aas. 8585 mentions numerous options. This doesn’t feel like something
that should be in a router requirements document. I suspect we have enough
operational experience at this point to make a specific recommendation;
probably NAT64/464xlat. If we aren’t ready to do that, I don’t think we’re
ready to include this in 7084bis.

Op zo 6 aug 2023 om 12:45 schreef Ole Trøan <otroan=
[e-mail]>

>
>
> > On 6 Aug 2023, at 18:02, Xipengxiao <xipengxiao=
> [e-mail]> wrote:
> >
> > 
> >>
> >>> I think it will be very useful to update both documents into a single
> one and include other points that we discussed in the list several times
> >
> > I agree with Jordi that it's a good idea to merge 7084 and 8585 to have
> a single requirement RFC for IPv6 CPEs, rather than having two separate
> requirement RFCs, one for all IPv6 CPEs and another for IPv4-as-a-Service
> CPEs.  The latter can be a section in the overall document.  But doing so
> does require coordination with the 7084 authors.  Can Tim/Gabor/Jordi
> please do so?  Thanks.
>
> I don’t think that’s a good idea. For the same reasons stated when we had
> this discussion last.
> IPv4aaS would belong in a IPv4 CE document. Not in an IPv6 one.
>
> O.
>
>
> >
> > XiPeng
> >
> > -----Original Message-----
> > From: v6ops <[e-mail]> On Behalf Of
> [e-mail]
> > Sent: Wednesday, August 2, 2023 10:17 PM
> > To: IPv6 Operations <[e-mail]>
> > Subject: Re: [v6ops] Update of RFC 7084 -- Re: Slides from AWS, SAP,
> ESnet, Dell in side meeting and call for volunteers on 3 research topics
> >
> > When I was working in RFC8585, for long time, the intent was to update
> RFC7084, and it went well at the 1st stage, but then, there was a
> push-back, mainly from RFC7084 authors … so we needed to find an
> alternative way.
> >
> > So if we now want to do that, I’m happy to go back and work on that
> together with Tim, Gabor or any others. I think it will be very useful to
> update both documents into a single one and include other points that we
> discussed in the list several times.
> >
> > Regadrs,
> > Jordi
> >
> > @jordipalet
> >
> >
> >> El 2 ago 2023, a las 22:01, Brian E Carpenter <
> [e-mail]> escribió:
> >>
> >> Gábor,
> >>
> >> RFC 8585 is Informational, like RFC 7084, so although updates/updated
> by is theoretically possible, this isn't really a bug.
> >>
> >> I agree that it's time to update RFC 7084, and maybe make it a BCP this
> time.
> >>
> >> Regards
> >>  Brian Carpenter
> >>
> >>> On 03-Aug-23 04:26, Gábor LENCSE wrote:
> >>> Hi Tim and Xipeng,
> >>> If you plan to update (or re-issue) RFC7084 “Basic Requirements for
> >>> IPv6 Customer Edge Routers”, then I recommend you to consider that,
> >>> IMHO, some of its content is outdated. It mentions only 6rd (which I
> >>> consider to be rather obsolete today) and DS-Lite. Since then RFC
> >>> 8585 “Requirements for IPv6 Customer Edge Routers to Support
> >>> IPv4-as-a-Service” has been published, but in the header of RFC 7084
> >>> a reference to RFC 8585 is missing. (It should have: "updated by RFC
> >>> 8585.) Perhaps Section 4.4 "Transition Technologies Support" (
> >>> https://datatracker.ietf.org/doc/html/rfc7084#section-4.4 ) should be
> >>> replaced by a pointer to RFC 8585. :-) Best regards, Gábor
> >>> 8/2/2023 6:08 PM keltezéssel, Xipengxiao írta:
> >>>>
> >>>> Hi Tim,
> >>>>
> >>>> I agree that we should update RFC7084 “Basic Requirements for IPv6
> Customer Edge Routers” to advise against EUI-64.  At a first thought, I
> wondered whether such an update is a bit too “ad hoc” (we update it every
> time we discover an issue). But at a second thought, I think the CPE
> requirement RFC is an important RFC that should be kept “up to date”.
> Although it’s not ideal to frequently update/publish new (requirement)
> RFCs, it’s easier to update RFCs than to deal with operations issues in the
> field.  So if you are willing, please work with the existing authors of
> 7084 to update it. thanks.
> >>>>
> >>>> XiPeng
> >>>>
> >>>> *From:* Timothy Winters <[e-mail]>
> >>>> *Sent:* Wednesday, August 2, 2023 2:42 PM
> >>>> *To:* Xipengxiao <[e-mail]>
> >>>> *Cc:* Ryo Yanagida <[e-mail]>; [e-mail]
> >>>> *Subject:* Re: [v6ops] Slides from AWS, SAP, ESnet, Dell in side
> >>>> meeting and call for volunteers on 3 research topics
> >>>>
> >>>> Hi XiPeng,
> >>>>
> >>>> I've responded inline to your questions.
> >>>>
> >>>> On Wed, Aug 2, 2023 at 4:12 AM Xipengxiao <xipengxiao=
> [e-mail]> wrote:
> >>>>
> >>>>   Hi Ryo,
> >>>>
> >>>>   Thanks for providing your thought. Your question “Is BCP about IID
> assignment the only thing that could be done as v6ops?” triggers me to
> think that:
> >>>>
> >>>>   1.Can some people in v6ops work with the authors to identify (the
> >>>> involved operators and) the guilty CPE models? Then something may be
> >>>> done (see below)
> >>>>
> >>>> [twinters] - If we truly believe that EUI-64 shouldn't be used, we
> should update 7084.  Either via a bis, or update RFC for this issue.  I'd
> be happy to be an author on this draft.
> >>>>
> >>>>   1.
> >>>>
> >>>>   2.Many people in v6ops are involved in various IPv6 Councils
> >>>> (e.g. of Belgium, UK).  They can talk about this issue in their
> >>>> countries to prevent repeat of this same mistake.  They can even
> >>>> talk to their regulators to issue directives
> >>>>
> >>>> [twinters] - IPv6 Ready Logo has a CE Router program that is used for
> regulators in some areas (Brazil).   One option would be to put a
> requirement in about using EUI-64 on the WAN.
> >>>>
> >>>>   1.
> >>>>
> >>>>   2.Should the operators stuck with EUI-64 CPEs do NAT66 to hide
> their customers’ IPv6 addresses?  I know NAT is not a popular idea in IPv6,
> but compared to allowing (bad) people to locate your customers’ IPv6
> addresses to the street level, maybe NAT66 is less evil?
> >>>>
> >>>> [twinters] - I've spoken to operators in some areas that are
> investigating requiring privacy addressing on the WAN for this reason.
> When it's inside the house, not connected to the ISP network it's much
> harder to control, I haven't heard of any operator looking into NAT66.
> >>>>
> >>>>   1.
> >>>>
> >>>>   To all - these are preliminary thoughts.  I am not really
> advocating them so please don’t be upset if you dislike them. I just hope
> v6ops people don’t conclude too quickly that nothing can be done.  To me
> this is an operations issue, and it’s up to us to deal with it.
> >>>>
> >>>>   XiPeng
> >>>>
> >>>>   *From:* Ryo Yanagida <[e-mail]>
> >>>>   *Sent:* Tuesday, August 1, 2023 5:01 PM
> >>>>   *To:* Xipengxiao <[e-mail]>
> >>>>   *Cc:* [e-mail]
> >>>>   *Subject:* Re: [v6ops] Slides from AWS, SAP, ESnet, Dell in side
> >>>> meeting and call for volunteers on 3 research topics
> >>>>
> >>>>   Hi Xipeng,
> >>>>
> >>>>   Thanks for sending this through.
> >>>>
> >>>>       On 29 Jul 2023, at 01:15, Xipengxiao <xipengxiao=
> [e-mail]> wrote:
> >>>>
> >>>>       New report from MAPrg on Friday.  Does v6ops need to do
> anything?
> >>>>
> >>>>       oWe present IPvSeeYou, a privacy attack that permits a remote
> and unprivileged adversary to physically geolocate many residential IPv6
> hosts and networks with street-level precision. The crux of our method
> involves: 1) remotely discovering wide area (WAN) hardware MAC addresses
> from home routers; 2) correlating these MAC addresses with their WiFi BSSID
> counterparts of known location; and 3) extending coverage by associating
> devices connected to a common penultimate provider router.
> >>>>
> >>>>       oWe first obtain a large corpus of MACs embedded in IPv6
> addresses via high-speed network probing. These MAC addresses are
> effectively leaked up the protocol stack and largely represent WAN
> interfaces of residential routers, many of which are all-in-one devices
> that also provide WiFi. We develop a technique to statistically infer the
> mapping between a router's WAN and WiFi MAC addresses across manufacturers
> and devices, and mount a large-scale data fusion attack that correlates WAN
> MACs with WiFi BSSIDs available in wardriving (geolocation) databases.
> Using these correlations, we geolocate the IPv6 prefixes of >12M routers in
> the wild across 146 countries and territories. Selected validation confirms
> a median geolocation error of 39 meters. We then exploit technology and
> deployment constraints to extend the attack to a larger set of IPv6
> residential routers by clustering and associating devices with a common
> penultimate provider router. While we responsibly
> >>>>       disclosed our results to several manufacturers and providers,
> the ossified ecosystem of deployed residential cable and DSL routers
> suggests that our attack will remain a privacy threat into the foreseeable
> future.
> >>>>
> >>>>   On this particular point. If I understand this correctly, it this
> is an issue with ISP/Vendor’s IID assignment in the CPEs. Is BCP about IID
> assignment the only thing that could be done as v6ops? (I think there are
> probably several RFCs like RFC8064 that deters the use of link-layer
> address in EUI-64 generation for IIDs described in RFC4291 already) Maybe
> to encourage a firmware update to change the IID assignment mechanism?
> >>>>
> >>>>   I think the scope (and the trick) here is the existence of
> all-in-one devices that have an EUI64 IID in the northbound (and also
> potentially 802.11 wifi side) v6 addr. which is used here to provide a
> mapping from v6 prefix to the known BSSIDs locations.
> >>>>
> >>>>   Best,
> >>>>
> >>>>   Ryo
> >>>>
> >>>>   _______________________________________________
> >>>>   v6ops mailing list
> >>>>   [e-mail]
> >>>>   https://www.ietf.org/mailman/listinfo/v6ops
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> v6ops mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/v6ops
> >>> _______________________________________________
> >>> v6ops mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/v6ops
> >> _______________________________________________
> >> v6ops mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/v6ops
> >
> >
> > **********************************************
> > IPv4 is over
> > Are you ready for the new Internet ?
> > http://www.theipv6company.com
> > The IPv6 Company
> >
> > This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
> >
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>