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

[Ole Troan <[e-mail]>]

Mark,

> Your email reads like you are arguing against NAPT66, not NPTv6.
> 
> I'm arguing against NPTv6.

There are still some arguments you make that fit better against NAPT44, NAPT66 than NPTv6.

[Answering your points directly on top, instead of inline.]

Discovering outside address:
That _could_ be STUN. STUN could be integrated into the NPTv6 instance, or external.
Or some other address discovery mechanism could be used. A server could for example just use:
curl 'https://api64.ipify.org?format=json’

Discovery of outside address, and _traversal_ is not the same as NAPT.

SIP applications already has mechanisms (ICE) to discover outside address. TURN is not needed.

NPTv6 supports peer to peer. With the only difference that outside address(es) must be discovered.
Note that the outside address is constant for the min(lifetime of the internal address, outside prefix).

For multi-homing, yes of course there will be unreachable GUAs in the DNS in case of failure. Just like MPMH.

For servers you are assuming there are servers directly connected to the global Internet without any form of firewall in between.
And yes, the difference in that case is that a NPTv6 server needs to discover its outside address to put that in DNS.
That’s the _only_ difference.

Note also that NPTv6 does not allow for applications carrying network addresses in the application layer.
That’s bad practice anyway, and is rare, given the IPv6 Internet.

NPTv6 provides internal stable addressing. Isolating the internal network from external changes. I would argue that its easier to run servers in those networks than a network being exposed to flash renumbered addresses, and multiple changing prefixes with multi-homing. And therefore NPTv6 helps against centralisation rather than harms. This argument is of course subjective and time will tell.

Best regards,
Ole




> (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
> > --------------------------------------------------------------------
> 
> 
>