Re: [IPv6] New Version Notification for draft-bctb-6man-rfc6296-bis-01.txt

[Mark Smith <[e-mail]>]

Hi Ole,

Sorry not to get back to you sooner.

On Thu, 7 Dec 2023, 00:06 Ole Troan, <[e-mail]> wrote:

> Mark,
>
> Your email reads like you are arguing against NAPT66, not NPTv6.
>

I'm arguing against NPTv6.

(I"m glad you've used "NAPT66", I've been a bit confused by people using
NAT66 to refer to something different to NPT because to me "NAT" means 1:1
(from RFC 2663), so I read NAT66 as NPTv6, where as NAPT(44)/(66) is
1:many).


> NPTv6 is transport layer agnostic. And provides a static 1:1 mapping
> between inside and outside addresses.


> RFC6296, section 5 goes into details on application considerations for
> NPTv6.
>

Okay, I think I've missed or forgotten the later 5.2 section that mention
STUN, TURN etc., possibly because I would have expected the main and pretty
comprehensive "5.  Implications for Applications" text to mention the work
arounds like STUN etc., and then the next 5.1 section is about networking
issues, which tends to imply that application issues have been fully
discussed.


> Would you mind restating your points in that context?
>
> Btw, do you have a particular application in mind, it would be a useful
> exercise to see what it would take for it to work with NPTv6.
>


VoIP SIP and gaming traffic are two examples, as are servers inside/behind
the NPT.

There have been SIP over IPv6 implementations for quite a long time. SIP
handsets register their own addresses with the SIP servers.

Xbox uses peer-to-peer communications over IPv6.
https://archive.nanog.org/sites/default/files/wed.general.palmer.xbox_.47.pdf

Once there is a possibility of NPT then those two major applications will
have to implement STUN/TURN, and STUN/TURN servers will need to be
deployed, a deployment burden that doesn't currently exist with IPv6
without NPT.


Some sort of server behind NPT e.g. WWW server becomes an issue with DNS if
NPT has been deployed for redundancy. Either both post NPT GUA addresses
for the server have to be put in DNS, with the issue of an unreachable DNS
entry of one of the NPT redundant links fails and the corresponding long
time outs. Dynamic DNS updates from the server to remove the unreachable
isn't possible without STUN/TURN and some way for the server to detect the
NPT link failure event.


I think application developers will choose the most likely to work as well
as simplest application communications architecture.

In the possible presence of NPT (or NAT of any type), that is always a
client-server architecture, even when a peer-to-peer architecture would
better suit the application.

It's always client-server because clients that are likely behind NPT don't
have to implement STUN/TURN, and there doesn't have to be STUN/TURN servers.

For servers, it's simplest if the server is on the IPv6 Internet and the
server has a direct GUA address.

This is what I was getting to regarding NPT (NAT) encoding two classes of
devices at the network layer, and also encouraging Internet centralisation.
Devices likely behind NPT will be easiest to treat as application clients
only, never or rarely application peers or servers, and servers will be
most easily deployed on "outside" of NPT, i.e. on the Internet with PI GUA
addresses, likely at centralised cloud providers.


Regards,
Mark.








>
> Best regards,
> Ole
>
>
> >> Brian,
> >>
> >> Just on the ALG point.
> >>
> >
> > Related to applications, it needs to be pointed out that if
> > applications wish to benefit from a more direct peer-to-peer style
> > communications model, where the peers are located on the "inside" of
> > the NPT device, applications will need to implement one or more of the
> > following NAT traversal RFCs. As there is no way to detect the
> > presence or not of an upstream NPT device without implementing these
> > protocols, it becomes necessary to implement them in all peer-to-peer
> > communications model applications just in case there is an NPT device
> > present in the communications path.
> >
> > RFC 8445, Interactive Connectivity Establishment (ICE): A Protocol for
> > Network Address Translator (NAT) Traversal
> > RFC 6544, TCP Candidates with Interactive Connectivity Establishment
> (ICE)
> >
> >
> > There probably also needs to be some discussion about how NPT creates
> > two classes of hosts at the network layer, where the boundary between
> > the host classes occurs at the NPT device.
> >
> > Class 1 are hosts outside of the NPT device, meaning holding GUA
> > addresses that are not translated, and can therefore host applications
> > that follow client-server, peer-to-peer or a mix of those two
> > communications models, which ever suits, without applications having
> > to implement NAT traversal protocols.
> >
> > Class 2 hosts are those that are inside the NPT domain, meaning
> > holding addresses that are translated by the upstream NPT device e.g.
> > ULAs, and can only, by default, host the client component of
> > applications that follow a client-server model, when communicating
> > with the server component residing on hosts that outside of the NPT
> > domain, unless the application also implements the above NAT traversal
> > protocols.
> >
> >
> > Finally, because NPT creates a client only class of hosts, and imposes
> > a client-server model on applications residing on those hosts, it is
> > also codifying centralisation of the Internet, because it is encoding
> > at the network layer a default model of private addressed
> > clients/public addressed servers model over the Internet.
> >
> > (I won't be all that surprised if the following happens if NPT goes
> > standards track:
> >
> > - CGNAT vendors will implement it, because they will want to continue
> > to provide their customers with a post-IPv4 "solutions".
> >
> > - They will have a couple of ways to sell the deployment of CGNAT NPT:
> >
> >        - to facilitate flash renumbering of residential customers,
> > which would mean customers will be provided with ULA prefixes by
> > default rather than GUA prefixes.
> >
> >        - to create what would be an artifical public IPv6 address
> > upsell from a default of private addresses, similar to the IPv4
> > address public address upsell model that exists today (that isn't
> > artificial due to IPv4 address scarcity).
> >
> > That means residential and SOHO customers will cease to have GUA
> > prefixes, meaning their hosts will become Class 2/clients only by
> > default.)
> >
> > Regards,
> > Mark.
> >
> >>>>> I imagine that pushback will continue. In order to make the
> discussion rational rather than emotional, I think the "NPTv6
> Applicability" section needs major work. There are generalisations like
> "similar ALGs may be required for these applications to work through NPTv6
> Translators" and "creates complexity for DNS deployment... 'split DNS',
> which may add complexity to network configuration". I think that text needs
> to specify the necessary mitigations and give normative references.
> >>>> I kinda like the general text in the applicability section.
> >>>> What do you think about adding a separate Application Level Gateway
> section with text similar to:
> >>>> https://datatracker.ietf.org/doc/html/rfc4787#section-7
> >>>
> >>> Sure, as long as the general statements are supported by concrete
> technical details that's fine. I see that RFC4784 is a valid BCP, but it's
> scoped for UDP so that's a bit limiting.
> >>>
> >>> And then I have to wonder if any of the updates in RFC7857 are also
> relevant, although it explicitly excludes IPv6 from consideration.
> >>>
> >>>> ?
> >>>> Stating that ALGs if implemented should default to off. Don’t know if
> that text can be updated to say something along the lines of modern
> application protocols not including IP address references?
> >>>
> >>> Maybe, but of course that still leaves legacy protocols. Maybe we need
> ART area advice on that?
> >>
> >> I don’t think so. NPTv6 is transport layer agnostic, and does no TCP
> state tracking.
> >>
> >> What do you think about this paragraph for ALG considerations:
> >>
> >> "7.  Application Layer Gateways
> >>
> >>   As explainined in [RFC5382] and [RFC4787] Application Layer Gateways
> >>   (ALGs) interfer with UNSAF [RFC3424] methods or protocols that try to
> >>   be NAT-aware.  NPTv6 is designed to be transport layer agnostic and
> >>   an ALG would be incompatible with this design and the checksum-
> >>   neutral mapping.
> >>
> >>   It is RECOMMENDED that an NPTv6 translator does not include ALGs.
> >> “
> >>
> >> Cheers,
> >> Ole
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> [e-mail]
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
>
>
>