Re: [v6ops] I-D Action: draft-link-v6ops-6mops-00.txt

[Tom Herbert <[e-mail]>]

On Tue, Mar 5, 2024 at 11:04 AM Brian E Carpenter
<[e-mail]> wrote:
>
> On 05-Mar-24 14:29, Jen Linkova wrote:
> > On Tue, Mar 5, 2024 at 12:17 PM Brian E Carpenter
> > <[e-mail]> wrote:
> >> This draft is an excellent start.
> >
> > Thank you!
> >
> >> The security considerations seem a bit short.
> >
> > It's a side effect of the draft submission deadline ;) Will be fixed in -01 ;)
> >
> >>> This document does not introduce any privacy considerations
> >>
> >> Are we sure about that? For example, some people (not me) will claim
> >> that the privacy benefits of NAT are lost for the IPv6-only hosts.
> >
> > If we compare the proposed design with a dual-stack approach, the
> > privacy considerations are the same:
> > - if the destination is a dual-stack (or IPv6-only) IPv6 will be used
> > in both cases;
> > - if the destination is IPv4-only, the traffic will go through NAT44
> > (dual-stack) or NAT64 (IPv6-mostly)
> >
> > Would adding a text that privacy considerations are inherited from a
> > dual-stack design?
>
> What I realised when considering your question is that we have no generic
> reference for IPv6 privacy considerations. RFC 7721 is specific to address
> generation, RFC 7824 is specific to DHCPv6, RFC 8065 is specific to adaptation
> layers, and that's about it. So I guess it is reasonable to say that "mostly"
> adds no new privacy risks compared to dual stack, but the "only" hosts avoid
> all IPv4-related risks and may benefit from IPv6-related protections such as
> temporary addresses.
>
> The NAT lovers will disagree though, because they believe that NAT is a
> privacy feature.

Brian,

It's less about being a NAT lover, but more just realizing that CGNAT
offers better privacy in addressing that IPv6 without NAT (this has
been confirmed by LE,
https://www.internetsociety.org/blog/2018/03/cgn-ipv6-fighting-online-crime/).

Tom

>
>      Brian
>
> >
> >> Is there any interaction with site policies (dis)allowing temporary
> >> addresses? Any interaction with randomized MAC addresses?
> >
> > It's all existing in any other IPv6 deployment, right? Nothing
> > specific to IPv6-mostly. I didn't consider enumerating all IPv6
> > privacy implications, but maybe I should..
> >
> >> On 05-Mar-24 01:27, [e-mail] wrote:
> >>> Internet-Draft draft-link-v6ops-6mops-00.txt is now available.
> >>>
> >>>      Title:   IPv6-Mostly Networks: Deployment and Operations Considerations
> >>>      Author:  Jen Linkova
> >>>      Name:    draft-link-v6ops-6mops-00.txt
> >>>      Pages:   16
> >>>      Dates:   2024-03-04
> >>>
> >>> Abstract:
> >>>
> >>>      This document discusses an deployment scenario called "an IPv6-Mostly
> >>>      network", when IPv6-only and IPv4-enabled endpoints coexist on the
> >>>      same network (network segment, VLAN, SSID etc).
> >>>
> >>> The IETF datatracker status page for this Internet-Draft is:
> >>> https://datatracker.ietf.org/doc/draft-link-v6ops-6mops/
> >>>
> >>> There is also an HTML version available at:
> >>> https://www.ietf.org/archive/id/draft-link-v6ops-6mops-00.html
> >>>
> >>> Internet-Drafts are also available by rsync at:
> >>> rsync.ietf.org::internet-drafts
> >>>
> >>>
> >>> _______________________________________________
> >>> I-D-Announce mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/i-d-announce
> >>>
> >>
> >> _______________________________________________
> >> v6ops mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/v6ops
> >
> >
> >
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops