Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis

[Tim Chown <[e-mail]>]

On 23 Mar 2024, at 06:19, Ole Troan <otroan=[e-mail]> wrote:

On 23 Mar 2024, at 02:26, Brian E Carpenter <[e-mail]> wrote:

On 23-Mar-24 12:19, Ted Lemon wrote:
Ole, it sounds like you are saying that we don’t need end to end transparency. I don’t really know how to respond to that. Technology takes time to do right. At the moment I don’t know of the killer app for end to end, but certainly apps like signal and telegram would benefit from it. Lorenzo has brought up zoom, which uses its external address for rendezvous.

*Obviously* today's apps work around the problem of broken references caused by NAT, because they have to.

Why should we encumber future apps with this problem when we don't have to?

I wanted to point out that _even_ without NAT it’s quite tricky to get an end-to-end transparent application right.
And that we haven’t made it easier with ephemeral addressing, NAT64.
Presumably there will also be edge firewalls in IPv6 or some other security functions.

30 years in, someone must have built this application by now, if it’s nothing more than mosh.

On another tack, the cloud fees for v4 public addresses are an incentive to use e2e IPv6. If you want to run v6 to say AWS you can deploy v6 on your campus, and then push jobs there over v6 and save $40 per IP per year.

https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/

I haven’t seen if Google, MS, etc are doing the same.  Some other smaller cloud providers have been doing this for some time.

In the R&E world, the CERN experiments are heading towards v6-only, as they want all storage to be directly addressable, and potentially worker nodes too.

Tim

O.


 Brian

Op za 23 mrt 2024 om 08:10 schreef Ole Trøan <[e-mail] <mailto:[e-mail]>>
  On 22 Mar 2024, at 22:25, Ted Lemon <[e-mail] <mailto:[e-mail]>> wrote:

  
  You have a single address you can’t advertise in the dns, yes. If you had a GUA you could advertise it in the DNS and have confidence that it would be reachable for some time.  Sometimes you’d be wrong, but usually not. If you have two GUAs you advertise both and let happy eyeballs take care of it.
  Yes, hand-waving is not hard.
  Do we have an example application that does all that’s required? Open source?
  I struggle to think of anything, but surely someone must take advantage of the end to end transparency in IPv6…
  Cheers
  Ole

  Op za 23 mrt 2024 om 05:53 schreef Ole Troan <otroan=[e-mail] <mailto:[e-mail]>>

      Brian,

I don't support adoption.

When NAT was first introduced, I experienced a lot of trouble. There may be fewer problems these days, but I think the reason is that applications are built with NAT in mind. In other words, I think it limits the ability to create applications.

I think it is undesirable that something works in an environment without NAT but does not work in an environment with NAT. If this happens, should I fix the application or the network?

I think it would be desirable to regain an environment where applications can be created without restrictions, and I think that would make the Internet better.

Even though IPv6 can eliminate this restriction, I do not agree with restricting applications with NPTv6.
Could you say a little more about _how_ NPTv6 restricts applications?

That's a slightly strange question since the draft already has a "Implications for Applications" section. Possibly it needs modernisation.

      Perhaps I should have phrased it better. I meant what concerns he has outside of what’s already in the application section of the document.

But I think Naoki is missing the trade-off here, and the comparison with our bad experience with NAPT44
and even with NAT444 is too simple.

There are a few scenarios where NPTv6 makes things better for a user, because otherwise they will lose connectivity. Outside those scenarios, NPTv6 is a bad thing and should not be enabled.

It's quite different from NAPT44. I could not use any IPv4-only resource without NAPT44. I can use every IPv6 resource without NPTv6. That's the situation for the majority of users.

      I think we are somewhat glossing over the complexities of what a native IPv6 application would have to deal with if it was acting as server.
      And I don’t know if we have written this down or we have good patterns in implementations to follow.

      An IPv6 host has multiple addresses with different reachability properties and lifetimes. And they may or may not be ephemeral. No way for the host to know.
      It has to pick one, and avoid picking one that leaks any of the temporary addresses, and somehow get that registered in DNS.
      Or exchange the right set of addresses through something like ICE.
      Deal with the consequences when these addresses change.

      And if stuck behind a stateful firewall, an IPv6 application would have to do some sort of firewall traversal.
      And if the destination is behind a NAT64, it would have to do the full set of IPv4 NAPT traversal techniques (and most of these are now going to be endpoint dependent NATs).

      All this, without even involving NPTv6.
      In my NPTv6 setup, I have a single IPv6 address. With infinite lifetime.
From an application implementation perspective I am not convinced that this is not a lot easier to implement than the above with ephemeral global addressing.

      Cheers,
      Ole


      --------------------------------------------------------------------
      IETF IPv6 working group mailing list
      [e-mail] <mailto:[e-mail]>
      Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
      --------------------------------------------------------------------

  --------------------------------------------------------------------
  IETF IPv6 working group mailing list
  [e-mail] <mailto:[e-mail]>
  Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
  --------------------------------------------------------------------
--------------------------------------------------------------------
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
--------------------------------------------------------------------