Subject: [v6ops] AWS ipv6-only features

From: Ca By <[email-masked]>
Date: Thu, 25 Nov 2021 07:50:11 -0500

Fyi, aws has gone beyond perfunctory ipv6 support and has released a series
of enhancements, with a focus on ipv6-only scenarios, including nat64 /
dns64

https://aws.amazon.com/about-aws/whats-new/2021/11/aws-nat64-dns64-communication-ipv6-ipv4-services/

AWS has lapped Google and Azure in advanced network features, which is
really surprising given the early muscle Google developed at IPv6 launch
and a stronger need to differentiate …

---

From: Mark Smith <[email-masked]>
Date: Fri, 26 Nov 2021 07:09:26 +1100

On Thu, 25 Nov 2021, 23:51 Ca By, <[email-masked]> wrote:

> Fyi, aws has gone beyond perfunctory ipv6 support and has released a
> series of enhancements, with a focus on ipv6-only scenarios, including
> nat64 / dns64
>
>

AWS failed to do ULAs properly. 'ec2' could be a random global ID, but
unlikely when their service is "EC2".

Matters more here because they're exposing that to all of their tenants. I
think GUAs would have been better for these internal all tenant services.

I've never seen AWS participate here in 20 years, unlike G and M.

_______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Clark Gaylord <[email-masked]>
Date: Thu, 25 Nov 2021 15:41:44 -0500

Yeah AWS hold their cards close and don't seem to engage the community, but
they do have decent IPv6 coverage across the services. Notwithstanding that
the whole VPC concept has the whiff of ancient days about it; tonight we're
gonna network like it's 1999!

EC2 as part of the address is a great idea. I am so stealing that (can't
believe I haven't thought of it.)

---

From: Mark Smith <[email-masked]>
Date: Fri, 26 Nov 2021 07:49:20 +1100

On Fri, 26 Nov 2021, 07:41 Clark Gaylord, <[email-masked]> wrote:

> Yeah AWS hold their cards close and don't seem to engage the community,
> but they do have decent IPv6 coverage across the services. Notwithstanding
> that the whole VPC concept has the whiff of ancient days about it; tonight
> we're gonna network like it's 1999!
>

It's a terrible idea. The "Unique" in ULA is on purpose.

Getting IPv6 private addressing right
https://blog.apnic.net/2020/05/20/getting-ipv6-private-addressing-right/

>> Matters more here because they're exposing that to all of their tenants.
>> I think GUAs would have been better for these internal all tenant services.
>>

---

From: Clark Gaylord <[email-masked]>
Date: Thu, 25 Nov 2021 15:52:31 -0500

I'll summarize "getting IPv6 private addressing right" here:

Use global addressing.

There I fixed it for you :-)

---

From: Mark Smith <[email-masked]>
Date: Fri, 26 Nov 2021 07:53:50 +1100

> There I fixed it for you :-)

Since I wrote that, no, that is a very wrong summary.

>>>> Matters more here because they're exposing that to all of their
>>>> tenants. I think GUAs would have been better for these internal all tenant
>>>> services.
>>>>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Nov 2021 10:02:48 +1300

On 26-Nov-21 09:49, Mark Smith wrote:
> 
> 
> On Fri, 26 Nov 2021, 07:41 Clark Gaylord, <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Yeah AWS hold their cards close and don't seem to engage the community, but they do have decent IPv6 coverage across the services. Notwithstanding that the whole VPC concept has the whiff of ancient days about it; 
tonight we're gonna network like it's 1999!
> 
>     EC2 as part of the address is a great idea. I am so stealing that (can't believe I haven't thought of it.)
> 
> 

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.

     Brian

> https://blog.apnic.net/2020/05/20/getting-ipv6-private-addressing-right/ <https://blog.apnic.net/2020/05/20/getting-ipv6-private-addressing-right/>
> 
> 
> 
>     On Thu, Nov 25, 2021, 15:09 Mark Smith <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
>         On Thu, 25 Nov 2021, 23:51 Ca By, <[email-masked] <mailto:[email-masked]>> wrote:
> 
>             Fyi, aws has gone beyond perfunctory ipv6 support and has released a series of enhancements, with a focus on ipv6-only scenarios, including nat64 / dns64
> 
>             https://aws.amazon.com/about-aws/whats-new/2021/11/aws-nat64-dns64-communication-ipv6-ipv4-services/ <https://aws.amazon.com/about-aws/whats-new/2021/11/aws-nat64-dns64-communication-ipv6-ipv4-services/>
> 
>             AWS has lapped Google and Azure in advanced network features, which is really surprising given the early muscle Google developed at IPv6 launch and a stronger need to differentiate … 
> 
> 
>         AWS failed to do ULAs properly. 'ec2' could be a random global ID, but unlikely when their service is "EC2".
> 
tenants. I think GUAs would have been better for these internal all tenant services.
>             [email-masked] <mailto:[email-masked]>
>             https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> 
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> 
>

---

From: Clark Gaylord <[email-masked]>
Date: Thu, 25 Nov 2021 16:03:32 -0500

Seriously, it's a nice paper. Thanks for working on it and the
contribution.

On Thu, Nov 25, 2021, 15:54 Mark Smith <[email-masked]> wrote:

>>>>>> AWS has lapped Google and Azure in advanced network features, which
>>>>>> is really surprising given the early muscle Google developed at IPv6 launch

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 26 Nov 2021 08:51:53 +0900

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

---

From: [email-masked]
Date: Fri, 26 Nov 2021 10:02:41 +0100

Lorenzo,

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

O.

---

From: Mark Smith <[email-masked]>
Date: Fri, 26 Nov 2021 20:34:39 +1100

On Fri, 26 Nov 2021, 20:03 , <[email-masked]> wrote:

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

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 26 Nov 2021 09:35:02 +0000

It is a good attempt to push people for “U” in ULA.
Just it is not guaranteed without a Registry.
But the registry could not be for free.
Then ULA would become similar to GUA (except bloating Internet BGP table).
Deadlock.
Ed/
From: v6ops [mailto:[email-masked]] On Behalf Of Mark Smith
Sent: Thursday, November 25, 2021 11:54 PM
To: Clark Gaylord <[email-masked]>
Cc: IPv6 Ops WG <[email-masked]>
Subject: Re: [v6ops] AWS ipv6-only features

On Fri, 26 Nov 2021, 07:52 Clark Gaylord, <[email-masked]<mailto:[email-masked]>> wrote:
I'll summarize "getting IPv6 private addressing right" here:

Use global addressing.

On Thu, Nov 25, 2021, 15:49 Mark Smith <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, 26 Nov 2021, 07:41 Clark Gaylord, <[email-masked]<mailto:[email-masked]>> wrote:
Yeah AWS hold their cards close and don't seem to engage the community, but they do have decent IPv6 coverage across the services. Notwithstanding that the whole VPC concept has the whiff of ancient days about it; tonight we're gonna network like it's 1999!

On Thu, Nov 25, 2021, 15:09 Mark Smith <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, 25 Nov 2021, 23:51 Ca By, <[email-masked]<mailto:[email-masked]>> wrote:
Fyi, aws has gone beyond perfunctory ipv6 support and has released a series of enhancements, with a focus on ipv6-only scenarios, including nat64 / dns64

Matters more here because they're exposing that to all of their tenants. I think GUAs would have been better for these internal all tenant services.

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 26 Nov 2021 09:43:22 +0000

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:[email-masked]] On Behalf Of Mark Smith
Sent: Friday, November 26, 2021 12:35 PM
To: Ole Troan <[email-masked]>
Cc: IPv6 Ops WG <[email-masked]>; Lorenzo Colitti <lorenzo=[email-masked]>
Subject: Re: [v6ops] AWS ipv6-only features

On Fri, 26 Nov 2021, 20:03 , <[email-masked]<mailto:[email-masked]>> wrote:
Lorenzo,

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.

---

From: [email-masked]
Date: Fri, 26 Nov 2021 11:23:21 +0100

Mark,

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

Absolutely. And my point wasn't to argue the qualitative properties of NAT.
I was making the point that NATs in various forms also are prevalent in IPv6 and that an application cannot assume end to end transparent addressing.
(Addresses are ephemeral and of course applications shouldn't use them as identifiers anyhow.)

O.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 26 Nov 2021 12:34:25 +0000

Hello Eduard and all

There’s a neat technique that’s hinted in https://datatracker.ietf.org/doc/html/rfc4864#section-3.4 whereby:

- host in the ULA domain get their normal IPv6 addresses from the ULA space.
- MIPv6 home agents at the edge of the ULA domain expose global addresses to the world and place them on virtual links that serve as home links
- Nodes in the ULA space that need to talk outside of that space obtain a global address from the home agents and bind them using their ULA as MIPv6 CoA.
- When talking inside the ULA, Source Address selection picks a ULA as best match
- When talking to the outside, SSA picks a home address, and packets are tunneled back and forth to the HA, but only inside the domain.

The cool thing is that the outside view of the ULA domain is completely flat, would be  a single /64.
Nodes can also register to different HAs that pick their /64 from different ISPs to get multihoming. The HA can drop the tunnel when the ISP connectivity fails so the host uses only the other ISP.

Keep safe;

Pascal

Disclaimer: I believe I filed IPR on that method.

From: v6ops <[email-masked]> On Behalf Of Vasilenko Eduard
Sent: vendredi 26 novembre 2021 10:35
To: Mark Smith <[email-masked]>; Clark Gaylord <[email-masked]>
Cc: IPv6 Ops WG <[email-masked]>
Subject: Re: [v6ops] AWS ipv6-only features

It is a good attempt to push people for “U” in ULA.
Just it is not guaranteed without a Registry.
But the registry could not be for free.
Then ULA would become similar to GUA (except bloating Internet BGP table).
Deadlock.
Ed/
From: v6ops [mailto:[email-masked]] On Behalf Of Mark Smith
Sent: Thursday, November 25, 2021 11:54 PM
To: Clark Gaylord <[email-masked]<mailto:[email-masked]>>
Cc: IPv6 Ops WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] AWS ipv6-only features

Use global addressing.

---

From: Gert Doering <[email-masked]>
Date: Fri, 26 Nov 2021 15:12:37 +0100

Hi,

> aware of the scaling issue of doing that, however it seems to be working

Actually it's an impressive example of "if you use enough brute force,
an amazingly bad lookup mechanism can still be made to work".

Humans should not be thinking about numbers.  Humans should use names
for things, and have some sort of dictionary to do the lookup...
(oh wait, phone books *have* been a thing)

> It makes things callers-only, even when being a receiver would be far

This is more a problem of not having a name-to-number mapping service, 
and having N:1 NAT setups.

NPT66 does not have to be one-way.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Mon, 29 Nov 2021 03:41:37 +0000

If I don’t remember wrong, ULA has the format of 8(FC00::/7 + L bit)+40 global ID+16 subnet ID. RFC4193.
The only different between Fc00::/8 and Fd::/8 is about how to allocate the 40 bit Global ID, but they are using the same format. Though Fd::/8 is failed in standards over 10 years ago.

I do really understand how can they use fd00:ec2::/16 with manually configuration. Weird. Why not IPv6 GUA? Much easy to be managed. Do they run out of IPv6 GUA or tenants don’t want it?

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Friday, November 26, 2021 7:52 AM
To: Brian E Carpenter <[email-masked]>
Cc: IPv6 Ops WG <[email-masked]>
Subject: Re: [v6ops] AWS ipv6-only features

On Fri, Nov 26, 2021 at 6:03 AM Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:
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.

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Mon, 29 Nov 2021 06:14:10 +0000

Ha, I mean I don’t really understand…

From: v6ops [mailto:[email-masked]] On Behalf Of Chengli (Cheng Li)
Sent: Monday, November 29, 2021 11:42 AM
To: Lorenzo Colitti <lorenzo=[email-masked]>; Brian E Carpenter <[email-masked]>
Cc: IPv6 Ops WG <[email-masked]>
Subject: Re: [v6ops] AWS ipv6-only features

To: Brian E Carpenter <[email-masked]<mailto:[email-masked]>>

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 29 Nov 2021 15:15:52 +0900

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=
[email-masked]> wrote:

> *From:* v6ops [mailto:[email-masked]] *On Behalf Of *Mark Smith
> *Sent:* Friday, November 26, 2021 12:35 PM
> *To:* Ole Troan <[email-masked]>
> *Cc:* IPv6 Ops WG <[email-masked]>; Lorenzo Colitti <lorenzo=
> [email-masked]>
> *Subject:* Re: [v6ops] AWS ipv6-only features
>
>
>
>
>

---

From: Gert Doering <[email-masked]>
Date: Mon, 29 Nov 2021 08:08:22 +0100

Hi,

> applications like videoconferencing cannot work without a relay.

That ship has sailed long ago.  

All this stuff works by registering some sort of identity at a central 
server, and that server will relay the session setup (and knows the 
member IPs).

Nobody calls "an IP address".  So you need the registration/mapping service
anyway.

(And to find the central server, a magic service called "DNS" was invented)

Gert Doering
        -- NetMaster

---

From: Mark Smith <[email-masked]>
Date: Mon, 29 Nov 2021 19:58:12 +1100

So why do you bother with IPv6? You must have been perfectly happy with
IPv4 if you think there is nothing wrong with forcing end user devices to
be clients only.

https://blog.apnic.net/2016/10/26/trouble-nat-part-2/

---

From: Gert Doering <[email-masked]>
Date: Mon, 29 Nov 2021 10:03:40 +0100

Hi,

> IPv4 if you think there is nothing wrong with forcing end user devices to

This is not what I said, and NPT66 does not force an end user device to
be "client only" (which I already stated).

Rendevouz / getting the right address into the mapping service (be it
DNS or SIP or wathnot) is a bit more complex with NPT66.

But hey, what *I* want is not relevant anyway.

The world wants a client-and-cloud Internet.

Gert Doering
        -- NetMaster

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 29 Nov 2021 09:26:51 +0000

Videoconferencing is probably not a good example, because it is typically initiated from inside the NPT zone.
A better argument of the same sort would be a surveillance system inside the NPT zone.
In general, It may be a requirement to initiate the connection from the outside. 2-way initialization of communications has value.

But the IPv6 address could not be stable for 99.99% of hosts. IPv6-address is semi-permanent.
We could not bloat the Internet routing table to 50B of prefixes to accommodate “PI for everybody and everything”.
We could not bloat the Internet table even for 20M of prefixed that is needed for businesses that would like to have redundancy.
PA addresses always have a danger to be changed – it is up to the provider. Additionally, users could change providers.
It would be very difficult to organize “IPv6 addresses portability” by analogy to “Mobile number portability” that we have in many countries (100x scale down of 50B problem would not help too much).
NPT does not make this problem worse – IID is not translated (just copied), with IPv6 address portability or not.

Hence, No, the argument is not accepted.

NPT looks like the only solution now for MHMP.
Eduard
From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Monday, November 29, 2021 9:16 AM
To: Vasilenko Eduard <vasilenko.eduard=[email-masked]>
Cc: IPv6 Ops WG <[email-masked]>
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=[email-masked]<mailto:[email-masked]>> wrote:

Why NPT is bad?

Ed/
From: v6ops [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mark Smith
Sent: Friday, November 26, 2021 12:35 PM
To: Ole Troan <[email-masked]<mailto:[email-masked]>>
Cc: IPv6 Ops WG <[email-masked]<mailto:[email-masked]>>; Lorenzo Colitti <lorenzo=[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] AWS ipv6-only features

O.

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 29 Nov 2021 09:31:43 +0000

IPv6 is semi-permanent till the provider would not change the prefix or the user would not change the provider.
In this period, it is possible to use this IP address as static (if you want, because some registry or DNS is better).

NPT is completely orthogonal to this. It does not improve or create any additional problem for this situation.
IPv6 is just semi-permanent by itself.

Eduard
From: Mark Smith [mailto:[email-masked]]
Sent: Monday, November 29, 2021 11:58 AM
To: Gert Doering <[email-masked]>
Cc: Lorenzo Colitti <[email-masked]>; IPv6 Ops WG <[email-masked]>; Vasilenko Eduard <[email-masked]>
Subject: Re: [v6ops] AWS ipv6-only features

So why do you bother with IPv6? You must have been perfectly happy with IPv4 if you think there is nothing wrong with forcing end user devices to be clients only.

On Mon, 29 Nov 2021, 18:09 Gert Doering, <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Gert Doering
        -- NetMaster

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 29 Nov 2021 11:03:36 +0100

Is this discussion about Amazon Chime videoconferencing tool?

Is Amazon Chime working ok on IPv6?

Alex

list:
- Amazon Chime (IPv6?)
- Messenger Rooms (IPv6?)
- bluejeans.com of Verizon
- BBB bigbluebutton.org
- framateam.org (mattermost, IPv6)
- A Web Whiteboard
- Adobe Connect (IPv6)
- Hyperfair
- meetecho (IPv6)
- slack
- gather.town (~IPv6)
- GoTomeeting
- Microsoft Teams
- Webex (IPv6?)
- Google meet (IPv6)
- Talk Spirit
- Zoom
- Skype
- WiMi
- Jitsi (IPv6)
- Mattermost
- Matrix.org (IPv6)
- discord et twitch
- youcircuit
- pexip
- webconf.numerique.gouv.fr (jitsi, but no IPv6)

Alex

Le 29/11/2021 à 07:15, Lorenzo Colitti a écrit :
> On Fri, Nov 26, 2021 at 6:43 PM Vasilenko Eduard 
> <vasilenko.eduard=[email-masked] 
> <mailto:[email-masked]>> 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:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Mark Smith
>     *To:* Ole Troan <[email-masked] <mailto:[email-masked]>>
>     *Cc:* IPv6 Ops WG <[email-masked] <mailto:[email-masked]>>; Lorenzo
>     Colitti <lorenzo=[email-masked]
>     <mailto:[email-masked]>>
>     *Subject:* Re: [v6ops] AWS ipv6-only features____
> 
>     __ __
> 
>     __ __
> 
>     On Fri, 26 Nov 2021, 20:03 , <[email-masked]
>     <mailto:[email-masked]>> wrote:____
> 
>         Lorenzo,
> 
>          > 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.
> 
>         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.
> 
>         <https://www.ietf.org/mailman/listinfo/v6ops>____
> 
>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 29 Nov 2021 11:50:44 +0000

[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 <[email-masked]> on behalf of Lorenzo Colitti <lorenzo=[email-masked]>
Date: Monday, 29 November 2021 at 07:17
To: Vasilenko Eduard <vasilenko.eduard=[email-masked]>
Cc: IPv6 Ops WG <[email-masked]>
Subject: Re: [v6ops] AWS ipv6-only features

Why NPT is bad?

Ed/

O.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 29 Nov 2021 16:53:22 +0100

We should clarify what we mean by IPv6-only.

Many people in this discussion mean that an IPv6-only server is 
reachable from an IPv4-only client, via a conversion mechanism.

However, there exist also IPv6-only servers that are not reachable from 
IPv4-only clients.

As such, I think there are two kinds of 'IPv6-only' serverrs: those who 
are reachable from IPv4-only clients and those who are not.

Alex

Le 25/11/2021 à 13:50, Ca By a écrit :
> <https://aws.amazon.com/about-aws/whats-new/2021/11/aws-nat64-dns64-communication-ipv6-ipv4-services/>
>

---

From: Nick Buraglio <[email-masked]>
Date: Mon, 29 Nov 2021 10:13:18 -0600

"IPv6-only" tends to be a heavily interpreted term. In many instances the
term "IPv6-only" been defined as "the absence of IPv4", much more than that
is applying subjective and circumstantial attributes. Of course, this
definition is also subjective as many operating environments do not allow
for the disabling of the IPv4 stack. In the cases I work with, it has been
defined as "The absence of IPv4 for anything but communication internal to
an isolated system", which allows for an IPv4 stack to exist but not
communicate outside of a single system. Even this is a difficult task. Once
the external translation mechanisms get tossed into the mix the whole
conversation changes.

nb

On Mon, Nov 29, 2021 at 9:53 AM Alexandre Petrescu <
[email-masked]> wrote:

> > <

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 29 Nov 2021 17:34:16 +0000

I have a proposition to add one clarification word. Example:

·       IPv6-only for this node

·       IPv6-only for this service

·       IPv6-only for this domain

·       IPv6 only for <any other limiting zone>

Ed/

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Monday, November 29, 2021 6:53 PM
To: [email-masked]
Subject: Re: [v6ops] ipv6-only features

Many people in this discussion mean that an IPv6-only server is reachable from an IPv4-only client, via a conversion mechanism.

However, there exist also IPv6-only servers that are not reachable from IPv4-only clients.

As such, I think there are two kinds of 'IPv6-only' serverrs: those who are reachable from IPv4-only clients and those who are not.

Alex

> https://aws.amazon.com/about-aws/whats-new/2021/11/aws-nat64-dns64-com

> munication-ipv6-ipv4-services/

> <https://aws.amazon.com/about-aws/whats-new/2021/11/aws-nat64-dns64-co

> mmunication-ipv6-ipv4-services/>

> really surprising given the early muscle Google developed at IPv6

> launch and a stronger need to differentiate …

v6ops mailing list

---

From: Owen DeLong <[email-masked]>
Date: Mon, 29 Nov 2021 10:27:47 -0800

> On Nov 28, 2021, at 19:41 , Chengli (Cheng Li) <c.l=[email-masked]> wrote:
> 

Actually, fc00::/8 failed in standards. fd::/8 (equivalent to 00fd::/8) was never under consideration. fd00::/8 is the only part of ULA that gained any acceptance.
 
> I do really understand how can they use fd00:ec2::/16 with manually configuration. Weird. Why not IPv6 GUA? Much easy to be managed. Do they run out of IPv6 GUA or tenants don’t want it?

Well, within fd00::/8, you’re pretty much allowed to do anything you want, as the 40 bit is locally assigned with a “recommended” randomization procedure.
This means that while fd00:ec2::/16 is a _REALLY_ bad idea, it could be done without really violating the RFCs.

Owen

---

From: Nick Buraglio <[email-masked]>
Date: Mon, 29 Nov 2021 12:33:46 -0600

Thank you for writing some information on ULA, it's an important part of
IPv6 and not really discussed enough. Perhaps we should start another
thread, but I'd like to hear more about when you see this behavior:

*"ULAs are preferred over GUAs, so when a host is presented with both a ULA
and GUA as possible ways to reach a destination, the host will select the
ULA. Once the ULA destination address is chosen, the host will then choose
its ULA as a source address to reach the ULA destination. This preference
of ULA addressing over GUA addressing is the mechanism that provides
internal network connectivity independence from concurrent external
Internet connectivity."*

In testing and in practice I have experienced that exactly the opposite of
this is true in both day-to-day use and every single explicit test I have
done where ULA and GUA are present on both sides with a variety of hardware
platforms and operating systems. GUA is used in every scenario I test when
the AAAA records are all matching (i.e. appropriately correct DNS). I'm
happy to learn that I am incorrect, as it would make certain things easier,
but nothing so far in my experience has shown the described behavior.
Seemingly relevant to the discussion at hand, and definitely relevant to
enterprises and providers actively using or considering ULA.

nb

---

From: Owen DeLong <[email-masked]>
Date: Mon, 29 Nov 2021 12:05:03 -0800

> On Nov 29, 2021, at 10:33 , Nick Buraglio <[email-masked]> wrote:
> 
> Thank you for writing some information on ULA, it's an important part of IPv6 and not really discussed enough. Perhaps we should start another thread, but I'd like to hear more about when you see this behavior: 

We can agree to disagree on its importance.

> "ULAs are preferred over GUAs, so when a host is presented with both a ULA and GUA as possible ways to reach a destination, the host will select the ULA. Once the ULA destination address is chosen, the host will then choose its ULA as a source address to reach the ULA destination. This preference of ULA addressing over GUA addressing is the mechanism that provides internal network connectivity independence from concurrent external Internet connectivity."
> 
> In testing and in practice I have experienced that exactly the opposite of this is true in both day-to-day use and every single explicit test I have done where ULA and GUA are present on both sides with a variety of hardware platforms and operating systems. GUA is used in every scenario I test when the AAAA records are all matching (i.e. appropriately correct DNS). I'm happy to learn that I am incorrect, as it would make certain things easier, but nothing so far in my experience has shown the described behavior. 
> 
> 
The quote is from the RFCs, but implementors often do differently. It is not surprising that ULA is an absolute cock-up… I predicted as much when it was being discussed in the IETF. It’s one of the reasons I opposed ULA in general, but most especially the idea of ULA Coordinated.

> Seemingly relevant to the discussion at hand, and definitely relevant to enterprises and providers actively using or considering ULA. 

Yep… The moral of the story is that GUA works as intended and ULA is a bit of a mess.

Owen

> 
> nb
> 
> On Thu, Nov 25, 2021 at 2:49 PM Mark Smith <[email-masked] <mailto:[email-masked]>> wrote:
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Nov 2021 10:05:53 +1300

Nick,

On 30-Nov-21 07:33, Nick Buraglio wrote:
> /"ULAs are preferred over GUAs, so when a host is presented with both a 
ULA and GUA as possible ways to reach a destination, the host will select 
the ULA. Once the ULA destination address is chosen, the host will then choose its ULA as a source address to reach the ULA destination. This preference of ULA addressing over GUA addressing is the mechanism that provides internal network connectivity independence from concurrent external Internet connectivity."/
> 
> In testing and in practice I have experienced that exactly the opposite 
of this is true in both day-to-day use and every single explicit test I have done where ULA and GUA are present on both sides with a variety of hardware platforms and operating systems. GUA is used in every scenario I test when the AAAA records are all matching (i.e. appropriately correct DNS). 

Please be more precise about the scenario. Do you mean that both hosts have AAAA records for their GUAs *and* ULAs, and that the app uses DNS names, or what?

Nevertheless, default address selection in RFC6724 is that GUAs win over ULAs, so what you report is correct out-of-the-box behaviour. The description in Mark's blog is not the default scenario, but you could make it true by changing the RFC6724 policy table in all your hosts.

If an individual app *wants* to prefer ULAs, it's not hard, but it does have to be an explicit choice. (My implementation of GRASP, for example, explicitly picks ULA over GUA if both are available, and reverts to link-local if neither is available.)

> I'm happy to learn that I am incorrect, as it would make certain things 
easier, but nothing so far in my experience has shown the described behavior.
> Seemingly relevant to the discussion at hand, and definitely relevant to enterprises and providers actively using or considering ULA.

The default in RFC6724 was chosen precisely to avoid surprises for enterprises and providers. If you want ULAs as the default preference, you have 
to change something.

     Brian

>         Yeah AWS hold their cards close and don't seem to engage the community, but they do have decent IPv6 coverage across the services. Notwithstanding that the whole VPC concept has the whiff of ancient days about 
it; tonight we're gonna network like it's 1999!
>                 AWS has lapped Google and Azure in advanced network features, which is really surprising given the early muscle Google developed 
at IPv6 launch and a stronger need to differentiate …

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Nov 2021 10:10:48 +1300

On 30-Nov-21 09:05, Owen DeLong wrote:
> 
> 
>> On Nov 29, 2021, at 10:33 , Nick Buraglio <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> /"ULAs are preferred over GUAs, so when a host is presented with both a ULA and GUA as possible ways to reach a destination, the host will select the ULA. Once the ULA destination address is chosen, the host will then choose its ULA as a source address to reach the ULA destination. This preference of ULA addressing over GUA addressing is the mechanism that provides internal network connectivity independence from concurrent external 
Internet connectivity."/
>>
>> In testing and in practice I have experienced that exactly the opposite of this is true in both day-to-day use and every single explicit test I 
have done where ULA and GUA are present on both sides with a variety of hardware platforms and operating systems. GUA is used in every scenario I test when the AAAA records are all matching (i.e. appropriately correct DNS). I'm happy to learn that I am incorrect, as it would make certain things easier, but nothing so far in my experience has shown the described behavior.
> Yep… The moral of the story is that GUA works as intended and ULA is a bit of a mess.

I disagree. ULAs work fine for their intended purpose. That purpose is not "Net 10 for IPv6."

    Brian

---

From: Nick Buraglio <[email-masked]>
Date: Mon, 29 Nov 2021 15:19:59 -0600

---
Nick Buraglio
Planning and Architecture
Energy Sciences Network
+1 (510) 995-6068

> We can agree to disagree on its importance.

It's important in that it is out there, used, and arguably poorly
understood by the general IT community. the more we know about the
real-world implications, the better. You'll get no argument from me
regarding it's overall importance/usefulness.

>
> *"ULAs are preferred over GUAs, so when a host is presented with both a
> the ULA. Once the ULA destination address is chosen, the host will then
> choose its ULA as a source address to reach the ULA destination. This
> preference of ULA addressing over GUA addressing is the mechanism that
> provides internal network connectivity independence from concurrent
> external Internet connectivity."*
>
> The quote is from the RFCs, but implementors often do differently. It is
> not surprising that ULA is an absolute cock-up… I predicted as much when it
> was being discussed in the IETF. It’s one of the reasons I opposed ULA in
> general, but most especially the idea of ULA Coordinated.
>

What I am seeing (detailed a bit better in my next email response) is
pretty consistent.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 29 Nov 2021 13:27:16 -0800

> On Nov 29, 2021, at 13:10 , Brian E Carpenter <[email-masked]> wrote:
> 

Brian, the difference between theory and practice is that in theory, there is no difference.

So, you are correct that as documented, ULAs could be made to work fine for their intended purpose.

In reality, implementations differ widely and almost none of the most widely deployed implementations match the RFCs well enough
to fit your claim here.

As such, in practice, ULA is a bit of a mess.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Mon, 29 Nov 2021 13:29:11 -0800

> On Nov 29, 2021, at 13:19 , Nick Buraglio <[email-masked]> wrote:
> 
> 
> ---
> Nick Buraglio
> On Mon, Nov 29, 2021 at 2:05 PM Owen DeLong <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> It's important in that it is out there, used, and arguably poorly understood by the general IT community. the more we know about the real-world implications, the better. You'll get no argument from me regarding it's overall importance/usefulness. 

I’d say that’s more tragedy than important, but you are certainly free to chose your own adjectives to describe the situation.

It’s definitely misunderstood (for some pretty obvious reasons).
If it were better understood but the general IT community, it would be a lot less widely deployed, IMHO.

> What I am seeing (detailed a bit better in my next email response) is pretty consistent.  
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Nov 2021 10:43:24 +1300

On 29-Nov-21 20:08, Gert Doering wrote:
> member IPs).> 

Let's be even clearer. Discovery of peers and rendezvous with peers are
*required* functions for such services, regardless of IP version and
whether NAT or NPT is in use or not.

That doesn't mitigate the fact that NAT and NPT are very undesirable
things to have on your data path.

    Brian

---

From: Nick Buraglio <[email-masked]>
Date: Mon, 29 Nov 2021 15:44:44 -0600

On Mon, Nov 29, 2021 at 3:06 PM Brian E Carpenter <
[email-masked]> wrote:

> external Internet connectivity."/
> >
> of this is true in both day-to-day use and every single explicit test I
> have done where ULA and GUA are present on both sides with a variety of
> hardware platforms and operating systems. GUA is used in every scenario I
> test when the AAAA records are all matching (i.e. appropriately correct
> DNS).
>
> Please be more precise about the scenario. Do you mean that both hosts
> have AAAA records for their GUAs *and* ULAs, and that the app uses DNS
> names, or what?
>

In the testing I was performing to double check my notes I had this
scenario:

host 1 (linux, A for IPv4, AAAA for IPv6 GUA, AAAA for IPv6 ULA)
host 1 (linux, A for IPv4, AAAA for IPv6 GUA, AAAA for IPv6 ULA)
host 1 (MacOS 12.0.1, A for IPv4, AAAA for IPv6 GUA, AAAA for IPv6 ULA)
RouterOS based router 1 (RouterOS, A for IPv4, AAAA for IPv6 GUA, AAAA for
IPv6 ULA) - RouterOS seems to default to IPv4 for some dumb reason, even
when the source address is set to v6
All A and AAAA records match their respective hosts (i.e. host1.lab.int,
host2.lab.int, etc.)

In each case when I attempt to reach the devices I use the DNS record the
default is to the GUA, from the GUA, with the exception of Mikrotik which
by default uses IPv4 if it exists as an A record, even if specifying an
IPv6 src address.

>
> Nevertheless, default address selection in RFC6724 is that GUAs win over
> ULAs, so what you report is correct out-of-the-box behaviour. The
> description in Mark's blog is not the default scenario, but you could make
> it true by changing the RFC6724 policy table in all your hosts.
>
> If an individual app *wants* to prefer ULAs, it's not hard, but it does
> have to be an explicit choice. (My implementation of GRASP, for example,
> explicitly picks ULA over GUA if both are available, and reverts to
> link-local if neither is available.)
>

Understood.

> The default in RFC6724 was chosen precisely to avoid surprises for
> enterprises and providers. If you want ULAs as the default preference, you
> have
> to change something.
>

Right, which is functionally impossible for most commercial platforms
meaning it generally doesn't happen so get consistent behavior of ULA being
deprioritized.

> >         Yeah AWS hold their cards close and don't seem to engage the
> community, but they do have decent IPv6 coverage across the services.
> Notwithstanding that the whole VPC concept has the whiff of ancient days
> about
> >         EC2 as part of the address is a great idea. I am so stealing
> that (can't believe I haven't thought of it.)
> >
> >
> https://blog.apnic.net/2020/05/20/getting-ipv6-private-addressing-right/ <
> https://blog.apnic.net/2020/05/20/getting-ipv6-private-addressing-right/>
> >
> >
> >
> >                 Fyi, aws has gone beyond perfunctory ipv6 support and
> has released a series of enhancements, with a focus on ipv6-only scenarios,
> including nat64 / dns64
> >
> >
> >                 AWS has lapped Google and Azure in advanced network
> features, which is really surprising given the early muscle Google
> developed
> >             AWS failed to do ULAs properly. 'ec2' could be a random
> global ID, but unlikely when their service is "EC2".
> >
> >             Matters more here because they're exposing that to all of
> their tenants. I think GUAs would have been better for these internal all
> tenant services.
> >
> >                 https://www.ietf.org/mailman/listinfo/v6ops <
> https://www.ietf.org/mailman/listinfo/v6ops>
> >
> >             https://www.ietf.org/mailman/listinfo/v6ops <
> https://www.ietf.org/mailman/listinfo/v6ops>
> >
> >     https://www.ietf.org/mailman/listinfo/v6ops <
> https://www.ietf.org/mailman/listinfo/v6ops>
> >
> >

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 30 Nov 2021 08:40:32 +0000

Hi Nick,
Thanks for the discovery.
ULA has a few purposes. What you have disclosed defeats stability purpose (probably, the primary ULA purpose).
If the internal session is initiated on GUA, but GUA is correctly reclaimed (and deprecated) later then the session is interrupted
despite ULA being available to avoid interruption.

It effectively makes low value for all recommendations of RFC 7084 on ULA.
And the same problem for all other cases when ULA has been used for stability (like Homenet).

IMHO: It is the big problem. It is bigger than filtered EHs on the Internet.
How is it possible to fix it?

Eduard
From: v6ops [mailto:[email-masked]] On Behalf Of Nick Buraglio
Sent: Tuesday, November 30, 2021 12:45 AM
To: Brian E Carpenter <[email-masked]>
Cc: IPv6 Ops WG <[email-masked]>
Subject: Re: [v6ops] AWS ipv6-only features

On Mon, Nov 29, 2021 at 3:06 PM Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:
Nick,

In the testing I was performing to double check my notes I had this scenario:

host 1 (linux, A for IPv4, AAAA for IPv6 GUA, AAAA for IPv6 ULA)
host 1 (linux, A for IPv4, AAAA for IPv6 GUA, AAAA for IPv6 ULA)
host 1 (MacOS 12.0.1, A for IPv4, AAAA for IPv6 GUA, AAAA for IPv6 ULA)
RouterOS based router 1 (RouterOS, A for IPv4, AAAA for IPv6 GUA, AAAA for IPv6 ULA) - RouterOS seems to default to IPv4 for some dumb reason, even when the source address is set to v6
All A and AAAA records match their respective hosts (i.e. host1.lab.int<http://host1.lab.int>, host2.lab.int<http://host2.lab.int>, etc.)

In each case when I attempt to reach the devices I use the DNS record the default is to the GUA, from the GUA, with the exception of Mikrotik which by default uses IPv4 if it exists as an A record, even if specifying an IPv6 src address.

Understood.

Right, which is functionally impossible for most commercial platforms meaning it generally doesn't happen so get consistent behavior of ULA being deprioritized.

     Brian

>
> nb
>
> On Thu, Nov 25, 2021 at 2:49 PM Mark Smith <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>
>
>     On Fri, 26 Nov 2021, 07:41 Clark Gaylord, <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>         On Thu, Nov 25, 2021, 15:09 Mark Smith <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>
>
>             On Thu, 25 Nov 2021, 23:51 Ca By, <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>                 [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>             [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

---

From: Philip Homburg <[email-masked]>
Date: Tue, 30 Nov 2021 10:47:38 +0100

>    On Nov 29, 2021, at 10:33 , Nick Buraglio <[1][email-masked]>
>    wrote:
> 
>    "ULAs are preferred over GUAs, so when a host is presented with
>    both a ULA and GUA as possible ways to reach a destination, the
>    host will select the ULA. Once the ULA destination address is
>    chosen, the host will then choose its ULA as a source address
>    to reach the ULA destination. This preference of ULA addressing
>    over GUA addressing is the mechanism that provides internal
>    network connectivity independence from concurrent external
>    Internet connectivity."
> 
>    Yep... The moral of the story is that GUA works as intended and
>    ULA is a bit of a mess.

I'm a bit confused about this scenario.

Typically a hosts gets addresses from DNS. So this suggests that people
create DNS RR sets that contains both GUAs and ULAs.

Is this common practice somewhere? Do people expect that something sensible
will happen if you try that? Is it documented what should happen?

---

From: [email-masked]
Date: Tue, 30 Nov 2021 12:53:37 +0100 (CET)

> will happen if you try that? Is it documented what should happen?

Putting ULA addresses into the DNS doesn't sound like a great idea. It
might work in your lab, I certainly don't expect it to work on the
global Internet.

Steinar Haug, AS2116

---

From: David Farmer <[email-masked]>
Date: Tue, 30 Nov 2021 06:53:20 -0600

> might work in your lab, I certainly don't expect it to work on the

Putting local IPv4 addresses(RFC1918) in the DNS, ideally in a local view,
is quite common, especially in enterprise environments. I would expect ULA
IPv6 addressed in the DNS, ideally in a local view again, to become
commonplace, if/when enterprise adoption of IPv6 by enterprises becomes
commonplace.

So, yes it won’t work very well over the Internet, but that’s the intent,
or in other words that’s a feature, not bug, for those doing such a thing.

Thanks

David Farmer

===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Nick Buraglio <[email-masked]>
Date: Tue, 30 Nov 2021 08:19:09 -0600

> create DNS RR sets that contains both GUAs and ULAs.

Sure, why not? DNS split view is really common in large environments, and
even with a split view there is nothing precluding GUA to have records in
the internal view. Putting ULA in the global view won't buy much, but  IPv6
was designed for multiple addresses per interface with the expectation that
any or all can be used. It's been clearly communicated that memorizing
addresses in v6 is a fools errand, so why should each address *not* have
DNS relevant to the locality of its use? I am not trying to assert that
this is a good idea, but it happens in the wild.

>
> Is this common practice somewhere?

Unknown to me.

> Do people expect that something sensible
> will happen if you try that?

We should have a clear and consistent order of operations, if we don't then
we have a problem because this is a model that I have seen in the wild and
I expect it will only proliferate.

> Is it documented what should happen?
>

That's exactly what we're discussing.

---

From: Nick Buraglio <[email-masked]>
Date: Tue, 30 Nov 2021 08:22:19 -0600

On Tue, Nov 30, 2021 at 5:54 AM <[email-masked]> wrote:

> Putting ULA addresses into the DNS doesn't sound like a great idea.

No argument there.

> It

Of course. However, a monumental amount of production DNS exists that isn't
part of the glocal DNS infrastructure.

---

From: Owen DeLong <[email-masked]>
Date: Tue, 30 Nov 2021 09:14:33 -0800

> On Nov 30, 2021, at 01:47 , Philip Homburg <[email-masked]> wrote:
> 

Probably more common in mDNS than DNS, but yes, something sensible SHOULD
happen as documented in the RFCs:

AAAA record sorting in getaddrinfo() or getnameinfo() should return the ULA records
before the GUA records in the linked list.

As a result, an application that sensibly iterates through the list in order (as is expected
behavior) should connect via GUA if possible (if not, it should rapidly receive an error
and move on to the next item in the list, so no extraordinary processing or coding
is required in the application).

Owen

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 1 Dec 2021 08:57:38 +1300

> before the GUA records in the linked list.

That should be an application programmer's choice, I think, because whether
ULAs should be preferred is an application-specific choice. In some cases,
a "happy eyeballs" heuristic might even be best. In any case, I don't see
how the IETF can design a one-size-fits-all solution.

Also, of course, there are choices like: does a printer need a GUA? Why
wouldn't a ULA be sufficient? The same goes for any internal-use-only
server.

Also a site could decide not only to use split-horizon DNS, but also
to use different DNS names for different addresses, e.g.
[email-masked] for the ULA and [email-masked]
for the GUA.

We abandoned draft-ietf-v6ops-ula-usage-recommendations and draft-ietf-v6ops-ula-usage-considerations. Maybe it's time to restart such an effort.

    Brian

---

From: Owen DeLong <[email-masked]>
Date: Tue, 30 Nov 2021 12:49:20 -0800

> On Nov 30, 2021, at 11:57 , Brian E Carpenter <[email-masked]> wrote:
> 

Well… The application programmer is free to go to extraordinary measures to traverse
the results from getaddrinfo() in whatever manner they wish, but the intended modus
operandi and the path of least surprise is to read the list in order and the order (absent
administrator interference in the source address selection choice via configuration)
will be ULA then GUA for all of the most obvious reasons.

> wouldn't a ULA be sufficient? The same goes for any internal-use-only

Right, but if the printer has ULA only and no GUA AAAA record, then this entire
discussion is a non-issue as address selection is moot if there’s only one choice.

> [email-masked] for the ULA and [email-masked]

Again, only one name is getting queried at a time in getaddrinfo(), so
something like that is moot as each name would return only one address.

We’re talking about what happens when a single query returns multiple
AAAA records, some of which are each of {ULA,GUA}.

> We abandoned draft-ietf-v6ops-ula-usage-recommendations and draft-ietf-v6ops-ula-usage-considerations. Maybe it's time to restart such an effort.

Personally, I’d favor abandoning ULA altogether, but I know that’s not a popular view.

Owen

---

From: Philip Homburg <[email-masked]>
Date: Wed, 01 Dec 2021 07:35:49 +0100

> Probably more common in mDNS than DNS, but yes, something sensible
> SHOULD happen as documented in the RFCs:
> 
> AAAA record sorting in getaddrinfo() or getnameinfo() should return
> the ULA records before the GUA records in the linked list.
> 
> As a result, an application that sensibly iterates through the list
> in order (as is expected behavior) should connect via GUA if possible
> (if not, it should rapidly receive an error and move on to the next
> item in the list, so no extraordinary processing or coding is
> required in the application).

mDNS is a bit of a boring case. If you get an mDNS reply is likely that the
destination is on the same subnet. It is possible to mess that up, but
that is more upto the network admin.

With DNS, how is it sensible to put both a ULA and a GUA in a single
DNS record?  Without happy eyeballs (and anything that is not
a webbrowser is unlikely to implement happy eyeballs), putting in two 
addresses for a host just means waiting twice as long when the host is
down.

What benefit do you expect to get from putting two addresses for the same
host in DNS (at the same DNS name, in the same view)?

Having two views (or names), one for external use with a GUA and one internal
use with ULA makes sense.