Re: [v6ops] AWS ipv6-only features

[obvioulsy without any hat]

Normally, STUN (RFC 5389) supports IPv6 so any 'inside-NPT' node can discover its 'global-after-NPT' IPv6 address, then ICE (RFC 8445) should allow end-to-end communication. Disclaimer: it has been a longgg time since I read STUN/ICE though...

Regards,

-éric

From: v6ops <v6ops-bounces@ietf.org> on behalf of Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
Date: Monday, 29 November 2021 at 07:17
To: Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] AWS ipv6-only features

With NPTv6, you can't tell a peer what address they can reach you at. So applications like videoconferencing cannot work without a relay.

On Fri, Nov 26, 2021 at 6:43 PM Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org<mailto:40huawei.com@dmarc.ietf.org>> wrote:
NPT is 2-way communication.
I do not understand why people are still talking about NAT66
If NPT exists.
It is better and cover all use cases.
Hence, 1-way communication is not an argument. Use NPT.

Renumbering is not an argument
Because it is always the case for PA addresses and people are happy with it now.

Why NPT is bad?

Ed/
From: v6ops [mailto:v6ops-bounces@ietf.org<mailto:v6ops-bounces@ietf.org>] On Behalf Of Mark Smith
Sent: Friday, November 26, 2021 12:35 PM
To: Ole Troan <otroan@employees.org<mailto:otroan@employees.org>>
Cc: IPv6 Ops WG <v6ops@ietf.org<mailto:v6ops@ietf.org>>; Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org<mailto:40google.com@dmarc.ietf.org>>
Subject: Re: [v6ops] AWS ipv6-only features

On Fri, 26 Nov 2021, 20:03 , <otroan@employees.org<mailto:otroan@employees.org>> wrote:
Lorenzo,

> True, and I can't condone it, but as long as they don't leak it, the only
> operator that can be damaged is AWS itself, so it's an own goal. In fact,
> even if they do leak it, any competent ISP will drop it.
>
> The damage is not to operators, it is to application developers. Using fd00:ec2::/16 pretty much guarantees that there will be collisions within EC2 itself. If collisions can happen, that means that applications will need to learn to work with NAT66 or at least with NPTv6. That's pretty much the worst thing they could have done for IPv6 I think.

I agree that damage is bad. Unfortunately that cat is already out of the bag.
IPv6 applications already need to work through NAT64.

And likely enterprises running on ULAs with NPTv6 gateways and "firewall in the cloud" style services which typically use NAT66/NPTv6 too.

Here's an example I think of to demonstrate the point.

I've had the same mobile phone number since 1995, and anybody who knows it can still call me on it.

That's across multiple carriers due to number portability (and I'm quite aware of the scaling issue of doing that, however it seems to be working well enough).

Imagine not even knowing your own phone number. That's what NAT is doing. It makes things callers-only, even when being a receiver would be far better.

O.

_______________________________________________
v6ops mailing list
v6ops@ietf.org<mailto:v6ops@ietf.org>
https://www.ietf.org/mailman/listinfo/v6ops