Subject: [v6ops] Thoughts about wider operational input

From: Fred Baker <[email-masked]>
Date: Mon, 21 Mar 2022 13:33:10 -0700

I have thought some about the discussion we had in the V6ops meeting about increasing operational input. Several suggestions were made: add a separate meeting, segregate parts of the meeting, attend the IEPG, use an interim, and so on. One thought that I had was to schedule a meeting at RIPE in May.

None of these address what seems to me to be a core problem: ISPs are deploying, but enterprise isn’t. How do we get enterprise on board?

Sent using a machine that autocorrects in interesting ways...

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 21 Mar 2022 21:56:19 +0100

Hi Fred, all,

I've thought about this many times, and I've myself confronted views:
1) Enterprises will come on-board when they really need it and start feeling the pressure, same as ISPs did/are doing.
2) We've failed with enterprises, as we are missing a better solution for multihoming.

No need to explain 1.

Of course, 2 only apply to certain "size" of enterprises. For example, SMEs that don't require multihoming or don't need to expose their internal services to "outside", could just survive with whatever prefix is assigned by the ISP, even if is not persistent, or even they can get assigned a PI from the relevant RIR and agree with their ISP to route it, so no need for BGP.

However, many organizations that today already use multihoming but still don't do BGP, definitively will require a PI prefix and they will need to have their own BGP router (very expensive, complex, lack of trained staff, etc.), or play ugly tricks.

I don't believe the right way is conditional RAs (RFC8475), neither using the experimental NPT (RFC6296).

A definitive solution may not be just an operational issue, so perhaps outside v6ops chapter, unless we can think in a new "magic", which then can definitively improve getting the enterprises moving on faster.

Regards,
Jordi
@jordipalet

El 21/3/22, 21:33, "v6ops en nombre de Fred Baker" <[email-masked] en nombre de [email-masked]> escribió:

    Sent using a machine that autocorrects in interesting ways...
    _______________________________________________
    v6ops mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/v6ops

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Mar 2022 10:05:02 +1300

Fred,

> None of these address what seems to me to be a core problem: ISPs are deploying, but enterprise isn’t. How do we get enterprise on board?

That will only happen when it hurts *not* to deploy IPv6 inside the enterprise.

I suggest reading the discussions that regularly crop up on "The Register" forums whenever they post an IPv6 story: always on the lines of "Why didn't those idiots make IPv6 backward-compatible with IPv4?"

Look at the comments on https://www.theregister.com/2022/01/24/opinion_column_ipv6/ for a sample.

    Brian

---

From: Nick Buraglio <[email-masked]>
Date: Mon, 21 Mar 2022 16:23:22 -0500

Enterprise input is difficult. Building interest is even harder for several
reasons, but the most prevalent reason I have seen is that there is a
severe lack of business case for deployment of IPv6 that enterprises can
see in short order. The key here is the timeframe. Most of even the largest
of enterprises are completely fine with - and even strongly advocate for -
private address space plus NAT, which many have conflated with a
security tool rather than a translation mechanism. Many larger enterprises
still rely on PA address space, IPv6 multihoming is significantly more
difficult for the same reasons that NAT is easy. Many of these
organizations do not have the expertise or the time to put IPv6 on the
radar until it is absolutely required by a business driver. These are
slowly coming, but they're slow. The slow rollout is adding to the
apprehension and laissez faire (at best) and outright refusal (at worst)
approach to consider IPv6.  De-mystifying the complex pieces are a huge
part of moving this forward. Making things approachable, easily consumable,
and friendly have been cornerstones to the experiences I have had
successfully deploying IPv6. To get enterprises interested it needs to be
worth their time in the short term and have wide and *emphatic* vendor
support across the enterprise platforms and for the protocol to be treated
as a first class citizen on those platforms, otherwise it is often viewed
as change for the sake of change. They need to be able to sample it and
model it in a way that is comfortable to them.
I don't believe that this is really a technology problem at its core.
Until we can make it work the same as what is believed to be "normal", it's
going to be a slog. When a vendor is asked if product X works without
legacy IP (or even supports IPv6) 95% need to say "well, yes, of course it
does" - or better yet, we should not need to ask. We don't need to ask if
things support IPv4, it's implied. The industry needs to be closer to that
mark.
Do I know how to get there? Not really. At this point I just yell as loud
as I can about IPv6 support everywhere I go and try to educate people the
best I can.

nb

On Mon, Mar 21, 2022 at 3:33 PM Fred Baker <[email-masked]> wrote:

> I have thought some about the discussion we had in the V6ops meeting about
> increasing operational input. Several suggestions were made: add a separate
> meeting, segregate parts of the meeting, attend the IEPG, use an interim,
> and so on. One thought that I had was to schedule a meeting at RIPE in May.
>
> None of these address what seems to me to be a core problem: ISPs are
> deploying, but enterprise isn’t. How do we get enterprise on board?
>

---

From: Nick Buraglio <[email-masked]>
Date: Mon, 21 Mar 2022 16:30:14 -0500

I realize I didn't really answer your question in my prior
rambling response. Perhaps a reasonable way to get some more enterprises
involved is to simply ask. Enterprises are typically driven by result
oriented processes. If we can determine something that they need, how could
we help them realize that need? How could their donation of time and input
be measured?
Engaging some of the larger enterprises that have deployed IPv6 -
successfully or unsuccessfully - and asking what their motivation was/is
would be a worthwhile endeavor. Moreover, determining why deployments have
been unsuccessful would be extremely useful in helping to inform
the motivations and pitfalls.

nb

On Mon, Mar 21, 2022 at 4:23 PM Nick Buraglio <[email-masked]> wrote:

> Enterprise input is difficult. Building interest is even harder for
> several reasons, but the most prevalent reason I have seen is that there is
> a severe lack of business case for deployment of IPv6 that enterprises can
>> I have thought some about the discussion we had in the V6ops meeting
>> about increasing operational input. Several suggestions were made: add a
>> separate meeting, segregate parts of the meeting, attend the IEPG, use an
>> interim, and so on. One thought that I had was to schedule a meeting at
>> RIPE in May.
>>

---

From: Fred Baker <[email-masked]>
Date: Mon, 21 Mar 2022 14:46:42 -0700

Following along these lines. We have had various and sundry talk about their IPv6 deployments in V6ops. Could we have an enterprise operator talk about what stops them from deploying? Looking for volunteers/suggestions.

> On Mar 21, 2022, at 1:33 PM, Fred Baker <[email-masked]> wrote:
>

---

From: Fred Baker <[email-masked]>
Date: Mon, 21 Mar 2022 14:50:14 -0700

> On Mar 21, 2022, at 2:05 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> "Why didn't those idiots make IPv6 backward-compatible with IPv4?"

To which the obvious answer is “IPv4 isn’t forward compatible with anything. It was designed to be replaced.”

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Mar 2022 11:42:12 +1300

> To which the obvious answer is “IPv4 isn’t forward compatible with anything. It was designed to be replaced.”

As has been said, in different words, many times on The Register forums. I think there are several IPv6ists who respond there, under various pseudonyms. (The Register is not a place where many people care to use real names.)

But unfortunately the usual reply is to repeat that we were idiots not to 
make IPv6 backwards-compatible (often accompanied by one of the many ideas proposed but found impossible in the early 1990s). Either that, or a plaintive "too hard" argument.

I agree with Jordi that multihoming is a genuine impediment. What isn't generally realised is that it's a problem of scale when considering at least 10,000,000 enterprises, much more than it's a problem of IPv6 itself.

---

From: Bob Hinden <[email-masked]>
Date: Mon, 21 Mar 2022 18:01:04 -0700

Brian,

I should probably know better to respond to this thread, but apparently not :-)

> On Mar 21, 2022, at 3:42 PM, Brian E Carpenter <[email-masked]> wrote:
> 

To add to what Fred said, IPv6 uses the transition mechanism that the Internet Protocol provided, that is the version number.

> But unfortunately the usual reply is to repeat that we were idiots not to make IPv6 backwards-compatible (often accompanied by one of the many ideas proposed but found impossible in the early 1990s). Either that, or a plaintive "too hard" argument.
> 

In my view, and I think I am agreeing with Nick said, it’s not a technical problem that would be fixed by a technical feature.   IPv4 works for most enterprises today and they don’t see a need (aka business case) to do anything different.   The Enterprises who are thinking about moving to IPv6 are very large enterprises who can’t live within the limits of private IPv4 space.

I suspect these are the ones we should be talking to.

Bob

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Tue, 22 Mar 2022 01:22:01 +0000

> I should probably know better to respond to this thread, but 

dito… and I don’t know what triggered this thread as .. as 
not-onsite and Fred wasn’t exactly saying.. Anyway…

> In my view, and I think I am agreeing with Nick said, it’s not a 
> technical problem that would be fixed by a technical feature.   IPv4 
> works for most enterprises today and they don’t see a need (aka 
> business case) to do anything different.   The Enterprises who are 
> thinking about moving to IPv6 are very large enterprises who can’t 
> live within the limits of private IPv4 space.

But remember that these XXL-enterprises are also seeking solutions and 
using ways often not feasible or applicable for the common SMLB.

> I suspect these are the ones we should be talking to.

I suspect the answer is more like “wait until they start speaking to 
you”; well, why should they?  IETF is on no radar for most of them ..  
so rather you have to go and “listen when and where they speak” 
because they do.

0.1ct/bz

---

From: Gert Doering <[email-masked]>
Date: Tue, 22 Mar 2022 09:30:56 +0100

Hi,

> I agree with Jordi that multihoming is a genuine impediment. What isn't generally realised is that it's a problem of scale when considering at least 10,000,000 enterprises, much more than it's a pr…

What is "an enterprise"?

My stance on this is that for "largely unmanaged SoHo networks" - which
could be called "small enterprise" - dual-enduser-ISP with dual-/48 or
NPT66 gets the job done in an easy and scalable way (HNCP would have
been great, but IETF politics killed it).

"Enterprise that truly need their own independent fully managed network
with multiple ISP uplinks and fully routed independent address space"
are probably way less than 10 million...

Half of them do not want Internet access anyway, just access to their
ALGs that will do the filtering and TLS inspection and everything, and
then out to the Internet as a new TCP session (= could be done with
DMZ islands of upstream-provider-allocated space just fine).

We need to work on our marketing regarding multihoming.  "What is it that
you get, what is the cost, which of the variants do you want, and why...?"

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: Vasilenko Eduard <[email-masked]>
Date: Tue, 22 Mar 2022 08:31:18 +0000

Hi all,

I agree with Jordi on MHMP, but the MHMP is potentially possible to solve.
Brian has shown the direction in RFC 8028.
We have detailed it more https://datatracker.ietf.org/doc/html/draft-vv-6man-nd-prefix-robustness-02
By the way, all the above does not block people to get a royalty from "provisioning domains" - parameters could be still delivered by HTTP. It is not in competition, something should be resolved on the ND level.

There is a much bigger problem that explains "why these idiots...":
Enterprises have a fixed budget (like 4% per year for the whole IT).
It is not possible to replace a lot for 1 year, 4% could lead to 25 years to finish the swap project (worst case).
It is difficult  (like in Telco) to develop a business case and ask for more money.
Hence, they need to do it very smoothly and very slowly.
Hence, "why these idiots make it not compatible".

Eduard

---

From: Gert Doering <[email-masked]>
Date: Tue, 22 Mar 2022 09:35:13 +0100

Hi,

> It is not possible to replace a lot for 1 year, 4% could lead to 25 years to finish the swap project (worst case).

This is a very poor argument, in many ways.

First, enterprise gear gets usually deprecated on "out of vendor support"
cycles, so in the 4-8 years range.

Then, with a bit of foresight in purchasing, IPv6 rollout won't require
*any* "hardware swap".

So, an enterprise that stated "we won't buy anything that is not IPv6
capable from day one (even if we do not want to turn it on today)" 5 years
ago will have a fully IPv6 capable entwork today.

Gert Doering
        -- NetMaster

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 22 Mar 2022 10:05:34 +0100

Yes, Brian said it, it is a much broader scalability problem.

Actually I think it will not make sense to think only in the "bigger" enterprises only, if we realize that it is very possible that even the "smaller" SMEs will wish be multihommed in the near future. Everybody becoming more dependant on Internet connectivity means you really want to pay links with two different providers, even for residential users.

May be not "active/active" connections for the SMEs, but something like main link being FTTH and secondary backup being 5G. So what I call "hybrid" CPEs and then we have the problem of resolving how to router their own PI.
 
Saludos,
Jordi
@jordipalet

El 22/3/22, 2:02, "v6ops en nombre de Bob Hinden" <[email-masked] en nombre de [email-masked]> escribió:

    Brian,

    Bob

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 22 Mar 2022 10:10:35 +0100

Maybe the terminology is not the most appropriate and we should talk about "organizations", because there are many types of networks that have the same problem and those are not enterprises (such as government sites, NGOs, etc.).

The problem is the same regardless of the "size" of the organization. The difference is that "today" most SMEs don't have that problem because they don't have PI, but it may turn the same when they realize that not being PI have renumbering issues if changing the ISP. Of course, again, if we talk about a "small" SME, then may not be an issue, they only have 40 or 50 devices to renumber (your mileage will vary), not easy but not "terrible".

On the rest of Gert comments, definitively I agree, and specially on our big mistake not working further on HNCP.
 
Regards,
Jordi
@jordipalet

El 22/3/22, 9:31, "v6ops en nombre de Gert Doering" <[email-masked] en nombre de [email-masked]> escribió:

    Hi,

    What is "an enterprise"?

    Gert Doering
            -- NetMaster

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Mar 2022 10:25:32 +0100

Is it really hncp that we needed here?  I think the key tech we need is
source-address-based forwarding, and babel i think has delivered that.
Granted, getting that into soho routers is a problem.

On Tue, Mar 22, 2022 at 10:11 JORDI PALET MARTINEZ <jordi.palet=
[email-masked]> wrote:

> Maybe the terminology is not the most appropriate and we should talk about
> "organizations", because there are many types of networks that have the
> same problem and those are not enterprises (such as government sites, NGOs,
> etc.).
>
> The problem is the same regardless of the "size" of the organization. The
> difference is that "today" most SMEs don't have that problem because they
> don't have PI, but it may turn the same when they realize that not being PI
> have renumbering issues if changing the ISP. Of course, again, if we talk
> about a "small" SME, then may not be an issue, they only have 40 or 50
> devices to renumber (your mileage will vary), not easy but not "terrible".
>
> El 22/3/22, 9:31, "v6ops en nombre de Gert Doering" <
> [email-masked] en nombre de [email-masked]> escribió:
>
>     Hi,
>
>     > I agree with Jordi that multihoming is a genuine impediment. What
> isn't generally realised is that it's a problem of scale when considering
> at least 10,000,000 enterprises, much more than it's a problem of IPv6
> itself.
>
>     What is "an enterprise"?
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
>
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 22 Mar 2022 10:34:22 +0100

You’re right. Let’s say it in a different way, as may be my first email was not clear on this.

I don’t think we want again to repeat the NAT problems, so NPT is not a valid solution for me.
I think in the future almost every site could want to be multihomed, in some cases “n” links active, many other cases just as a backup.
This means that renumbering is not (probably) a valid choice in any cases.
Can we make PI work in such “huge scale” scenario?
Can source-address forwarding work and solve all that, or we need that and/or something else.

Only if we solve this, organizations could learn that NAT with IPv6 is not the solution, but something better that provides the same results, and no need to have “private” addresses, because the way NAT is offering a “different” addressing inside and outside is not NAT per-se, but statefull firewalling.

Regards,

Jordi

@jordipalet

El 22/3/22, 10:27, "v6ops en nombre de Ted Lemon" <[email-masked] en nombre de [email-masked]> escribió:

Is it really hncp that we needed here?  I think the key tech we need is source-address-based forwarding, and babel i think has delivered that. Granted, getting that into soho routers is a problem. 

On Tue, Mar 22, 2022 at 10:11 JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:

Regards,
Jordi
@jordipalet

    Hi,

    What is "an enterprise"?

    Gert Doering
            -- NetMaster

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

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 22 Mar 2022 11:02:58 +0100

Jordi, *:

Isn't the main reason why we are not seeing more IPv6 in "enterprises" or even "homes"
exactly because NAT (even from rfc1918 addresses to IPv6) does work well enough
that those networks are happy to stick to it ? Why else would we likely have a huge
number of edge routers doing exactly that ?

If we'd overcome architectural purity desires, maybe we find more practical ways
to steer the evolution:

For example, if one can show benefits for e.g.: multihoming to different IPv6 services
by use of (call it what you want) address translation from IPv6 on-site to the different
IPv6 addresses in the Internet - then we might have created an incentive to upgrade from
IPv4 to IPv6 already. That's to me already one step. Its IMHO not creating more NAT
in the process, unless that NAT actually turns out to be providing more benefits for
the users than downsides. But thats just what we have to deal with: actual user
experience as opposed to architectural preferences.

Btw: To me as an end-user, a NAT/FW is great when i can control it (for my edge-network),
and it is terrible when somebody in "the Internet" forces it on me. I have no idea why
we're not even starting to think about these tools from exactly this perspective. Alas
RFC8990 does not recognize this difference.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Gert Doering <[email-masked]>
Date: Tue, 22 Mar 2022 11:09:36 +0100

Hi,

On Tue, Mar 22, 2022 at 10:10:35AM +0100, JORDI PALET MARTINEZ wrote:
> The problem is the same regardless of the "size" of the organization.
> The difference is that "today" most SMEs don't have that problem
> because they don't have PI, but it may turn the same when they
> realize that not being PI have renumbering issues if changing the
> ISP. Of course, again, if we talk about a "small" SME, then may not
> be an issue, they only have 40 or 50 devices to renumber (your
> mileage will vary), not easy but not "terrible".

This class of SMEs is what I meant with "largely unmanaged" networks.

If you do not put your IPv6 addresses into excel sheets or other 
"management systems", but just let SLAAC + bonjour do its job, I'd 
claim that a "renumbering event" basically isn't such a big deal.

Much less than "find an ISP that knows what PI is and is willing to
route it for you, for the same price as a PA/DHCPv6PD provisioned
service".

Combine "we do not put static IPv6 addresses on things, but let SLAAC
happen" with "everything that might need remote access (= addresses
would need to be known) is in someone's Cloud already", things get
even easier.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Tue, 22 Mar 2022 11:12:27 +0100

Hi,

> Granted, getting that into soho routers is a problem.

HNCP/Babel is exactly what we needed.

IETF bickering delayed that for 3+ years, and the market has sailed - 
there was a critical time window when plastic routers started adding
IPv6 support.  Homenet missed that opportunity, discussing routing
protocol options instead.  Now, plastic routers have IPv6 support,
and vendors see no incentive to add more code.

Feature velocitiy in pastic routers usually is paid for by ISPs ordering
tens of thousands, and I have heard clear voices that ISPs are not 
interested in features that help their customers to do multihoming
with the competition...

Gert Doering
        -- NetMaster

---

From: Xipengxiao <[email-masked]>
Date: Tue, 22 Mar 2022 10:16:19 +0000

>> Fred said: Following along these lines. We have had various and sundry talk about their IPv6 deployments in V6ops. Could we have an enterprise operator talk about what stops them from deploying? Looking for volunteers/suggestions.

In the NANOG discussion on "not making use of 240/4", there are a few people chanting against IPv6.  It may be good to invite some of them to talk about their technical concerns.   Then somebody from us can document all these concerns and solutions into a draft.  This solves problems.

While motivation is generally a bigger problem, even there I see momentum.  Many small and medium enterprises (SMEs) don't see the need for IPv6, as they don't need many addresses, and they may not have the IPv6 expertise to make the change.  But even for these SMEs, I see the recent support of IPv6 from Azure/AWS a potential game changer for this situation:  if the Azure/AWS makes the use of IPv6 default (current default is still IPv4), many SMEs will be moved to IPv6 with very little effort!  I see this as the biggest momentum for IPv6 in enterprise.

Lastly, let's not be too optimistic about IPv6 in network operators.  First, there are still many big operators that don't do IPv6.  If we are to spend some effort persuading somebody to do IPv6, talking with these operators (they have need for IPv6) will likely be more rewarding than with some enterprises (may not have need).  Second, many operators that have deployed IPv6 actually only deployed IPv6 in overlay (i.e. UEs & gateways like BNGs), not in underlay (routers).  When an operator tells you that they do Dual-Stack, you would think that their network can transport IPv6 packets natively.  But that is mostly NOT that case.  Only the UEs and BNGs/mobile gateways are Dual-Stack.  The routers are not.  The routers often just put IPv6 over MPLS.  The reason for doing so, is to use only an IPv4 data/control/management plane.  If they do Dual-Stack in underlay with the routers, they will have 2 data/control/management planes.  This was the biggest IPv6 surprise I found in 2021.  Many IPv6 veterans still don't realize this, or don't believe it.  If we can, I suggest we do a survey to verify what I said.   

In 16:45 today in Park Suite 9 in Vienna I will do a host techtalk on "IPv6 Adoption Worldwide: Momentum, Challenges and Next Steps".  It will touch many issues we discuss here.  I invite you to join the discussion on site or on line: https://wws.conf.meetecho.com/conference/?group=hostspeaker .  Thank you very much.

XiPeng

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 22 Mar 2022 11:41:19 +0100

If i have a network i control, call it enterprise, IoT, home, whatever. And i want to
multi-home. And the host-stacks of my devices are all different and have problems with
the most advanced IPv6 features. Why would it not be a desirable feature for me as the
end-user to have an IPv6/IPv6 NAT on the router towards the 3 Internet connections to
which i multi-home ? Sure, we can probably list some downsides, but they need to be
weighted against the benefits for me as an end user. Not ?

Cheers
    Toerless

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 22 Mar 2022 11:43:01 +0100

I don't think is a matter of being purist or not, it is a matter of ensuring that we don't create same or similar problems for apps.

Of course, as everything, it is a balance with what is feasible and not.

I believe in the homes, deployment is not a problem at the time being - CPEs with IPv6 are being provided by the ISPs that want to turn it on. The problem in enterprises is, most of of the cases, because, they didn't entered the proper "learning cycle for IPv6" (no need for it, no incentives, troubles if we don't have NAT, multihoming, etc.), so there is no request from IT to the managers and then there is no budget. Of course, there are exceptions, but I see this everyday specially in countries where the government mandated IPv6 in the public administration.
 
Regards,
Jordi
@jordipalet

El 22/3/22, 11:03, "Toerless Eckert" <[email-masked]> escribió:

    Jordi, *:

    Cheers
        Toerless

    -- 
    ---
    [email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Tue, 22 Mar 2022 11:43:10 +0100

> 2. I think in the future almost
>    every site could want to be
>    multihomed, in some cases "n" links active, many other cases
>    just as a backup.
> 3. This means that renumbering is not
>    (probably) a valid choice in
>    any cases. 
> 4. Can we make PI work in such "huge scale"
>    scenario?
> 5. Can source-address forwarding work and solve all
>    that, or we need
>    that and/or something else.

It seems unlikely to me that PI will work in a 'huge scale', so we are
left with poor man's multi-homing where the user's network will use addresses
provided by different ISPs.

For outbound connections we have good options. Putting the smarts in the
host means that a router only has to drop it's default route to get hosts
to switch to another upstream.

With babel, etc. multi homing can be transparent to hosts.

The big advantage compared to NAT is that with NAT you would have a single
NAT box with multiple uplinks. With IPv6 you can put that in different
routers. Giving redundancy against router failure.

Obviously, companies that care about multi-homing would need to ask about
routers that support babel. 

The unsolved problem I see is inbound connections. What do you put in DNS?
Who keeps information in DNS up-to-date.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Mar 2022 11:53:01 +0100

On Tue, Mar 22, 2022 at 11:44 AM Philip Homburg <[email-masked]>
wrote:

> Who keeps information in DNS up-to-date?

The assumption in Homenet was that the home network would maintain the DNS
zone, and it would contain all the reachable addresses. Of course, this was
hard and we never managed to publish a document describing how it worked.
But in practice I think this works reasonably well—we just don't have a
spec describing how to automate it.

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 22 Mar 2022 12:04:06 +0000

Hi Jordi,

I understand the desire to fix broken things. (I doubt it is possible)
But why NPT+ULA is not enough for MHMP now?
It is very similar to what Enterprises and small businesses have now.
They would be happy.

Eduard
From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
Sent: Tuesday, March 22, 2022 12:34 PM
To: [email-masked]
Subject: Re: [v6ops] Thoughts about wider operational input

  1.  I don’t think we want again to repeat the NAT problems, so NPT is not a valid solution for me.
  2.  I think in the future almost every site could want to be multihomed, in some cases “n” links active, many other cases just as a backup.
  3.  This means that renumbering is not (probably) a valid choice in any cases.
  4.  Can we make PI work in such “huge scale” scenario?
  5.  Can source-address forwarding work and solve all that, or we need that and/or something else.

Regards,
Jordi
@jordipalet

El 22/3/22, 10:27, "v6ops en nombre de Ted Lemon" <[email-masked]<mailto:[email-masked]> en nombre de [email-masked]<mailto:[email-masked]>> escribió:

On Tue, Mar 22, 2022 at 10:11 JORDI PALET MARTINEZ <jordi.palet=[email-masked]<mailto:[email-masked]>> wrote:
Maybe the terminology is not the most appropriate and we should talk about "organizations", because there are many types of networks that have the same problem and those are not enterprises (such as government sites, NGOs, etc.).

Regards,
Jordi
@jordipalet

El 22/3/22, 9:31, "v6ops en nombre de Gert Doering" <[email-masked]<mailto:[email-masked]> en nombre de [email-masked]<mailto:[email-masked]>> escribió:

    Hi,

    What is "an enterprise"?

    Gert Doering
            -- NetMaster

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

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 22 Mar 2022 12:07:15 +0000

Renumbering after any 3GPP uplink re-establishment?
With default timer for preferred of 1 week.

Ed/
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Gert Doering
Sent: Tuesday, March 22, 2022 1:10 PM
To: JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] Thoughts about wider operational input

Hi,

On Tue, Mar 22, 2022 at 10:10:35AM +0100, JORDI PALET MARTINEZ wrote:
> because they don't have PI, but it may turn the same when they realize 
> that not being PI have renumbering issues if changing the ISP. Of 
> course, again, if we talk about a "small" SME, then may not be an 
> issue, they only have 40 or 50 devices to renumber (your mileage will 
> vary), not easy but not "terrible".

If you do not put your IPv6 addresses into excel sheets or other "management systems", but just let SLAAC + bonjour do its job, I'd claim that a "renumbering event" basically isn't such a big deal.

Much less than "find an ISP that knows what PI is and is willing to route it for you, for the same price as a PA/DHCPv6PD provisioned service".

Combine "we do not put static IPv6 addresses on things, but let SLAAC happen" with "everything that might need remote access (= addresses would need to be known) is in someone's Cloud already", things get even easier.

Gert Doering
        -- NetMaster

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 22 Mar 2022 12:10:16 +0000

Hi Gert,
Small businesses are asking for less complexity, not more. They would probably ignore more complex options.
It is long-term anyway. Maybe it makes sense to do.
Eduard
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Gert Doering
Sent: Tuesday, March 22, 2022 1:12 PM
To: Ted Lemon <[email-masked]>
Cc: [email-masked]; JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
Subject: Re: [v6ops] Thoughts about wider operational input

Hi,

On Tue, Mar 22, 2022 at 10:25:32AM +0100, Ted Lemon wrote:
> Is it really hncp that we needed here?  I think the key tech we need 
> is source-address-based forwarding, and babel i think has delivered that.

IETF bickering delayed that for 3+ years, and the market has sailed - there was a critical time window when plastic routers started adding
IPv6 support.  Homenet missed that opportunity, discussing routing protocol options instead.  Now, plastic routers have IPv6 support, and vendors see no incentive to add more code.

Feature velocitiy in pastic routers usually is paid for by ISPs ordering tens of thousands, and I have heard clear voices that ISPs are not interested in features that help their customers to do multihoming with the competition...

Gert Doering
        -- NetMaster

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 22 Mar 2022 13:52:35 +0100

When you are saying that IPv6 at home is not a problem, does that
include homes with SP multihoming ? Because i for once don't think
that support for DNS especially in the large amount of IoT equipment
is good enoough to really make hiding of multiple addresses behind
DNS names work well enough in practice.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 22 Mar 2022 13:12:38 +0000

Good question Fred. 
As one of those enterprises "Dragging their heels" on IPv6, and knowing MANY others in the same state,   I believe the following are the core issues: 
1. Lack of technical knowledge regarding IPv6 implementation and operation.  
2. Lack of understanding of compelling reason(s) to deploy IPv6.   Both Technical and Business reasons.  

There is progress in both areas,  but definitely  not enough and results are slow (or worse).  

Another area that COULD be compelling is to highlight what issues may be faced if an Org stays on IPv4 only, for either the short or long term

Any help, guidance or info regarding either of the above would be helpful and appreciated.    

The best methods for doing this is a probably a longer discussion(s), so I will not attempt to address related details in this email.    
But I do believe this is any topic which warrants attention and would glad to contribute,  if I can.  

Thanks

Mike

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Fred Baker
Sent: Monday, March 21, 2022 4:33 PM
To: IPv6 Ops WG <[email-masked]>
Subject: [v6ops] Thoughts about wider operational input

[External email]

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

This message was secured by Zix(R).

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 22 Mar 2022 15:54:41 +0100

Hi Eduard,

What I meant is that I will like to avoid the issues that NAT creates for apps. We must aim for something better.

On the other side, using an experimental protocol for production networks, in my opinion is a big “NO”.

Regards,

Jordi

@jordipalet

El 22/3/22, 13:04, "v6ops en nombre de Vasilenko Eduard" <[email-masked] en nombre de vasilenko.eduard=[email-masked]> escribió:

Hi Jordi,

They would be happy.

Eduard

Regards,

Jordi

@jordipalet

Regards,
Jordi
@jordipalet

    Hi,

    What is "an enterprise"?

    Gert Doering
            -- NetMaster

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 22 Mar 2022 15:56:56 +0100

I meant a "common" home. Today it is not very usual to have multiple simultaneous active links in a home.

The solution for the DNS, probably was the one designed in homenet, as it has been mention before.
 
Regards,
Jordi
@jordipalet

El 22/3/22, 13:53, "v6ops en nombre de Toerless Eckert" <[email-masked] en nombre de [email-masked]> escribió:

    Cheers
        Toerless

    -- 
    ---
    [email-masked]

---

From: Gert Doering <[email-masked]>
Date: Tue, 22 Mar 2022 16:13:48 +0100

Hi,

> With default timer for preferred of 1 week.

If your equipment does silly things, bad results will happen.

So why would any sane vendor produce 3GPP routers that send a prefix
lifetime of 1 week?

This is not a new discussion, it's a well-understood issue, and it is
addressed in, for example, RFC8978, RFC9096 and draft-ietf-6man-slaac-renum

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Tue, 22 Mar 2022 16:14:55 +0100

Hi,

> Small businesses are asking for less complexity, not more. They would probably ignore more complex options.

HNCP is the least complexity a SME can have.

"Buy two routers, plug them together in an arbitrary fashion, get
multihoming".

Not even having to care about "LAN" or "WAN" ports.

I tested this with the OpenWRT implementation - it's really nice stuff.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Tue, 22 Mar 2022 16:20:43 +0100

Hi,

On Tue, Mar 22, 2022 at 11:41:19AM +0100, Toerless Eckert wrote:
> Why would it not be a desirable feature for me as the

This being an IETF list, it is not allowed to find anything-NAT beneficial.

OTOH, as an operator, I find this a viable option.

The reason why I prefer "host has multiple GUAs" better, in theory, is
that it gives the *user* more control on what he wants - like, "I can
run my bittorrent via the cable ISP, and SSH out via LTE", by selecting
the corresponding source IP = selecting the outgoing ISP.

Now, in practice, source address selection for "there are multiple GUAs
with different pros/cons attached" is lacking quite a bit.  And HNCP
routers with source-based forwarding can not be bought.  So all the
nice things do not work.

Which means, "a router with GUAs inside, a DSL port and a LTE modem and 
NPT66 on both outside interfaces" is a really nice redundancy solution 
for basically all "mostly unmanaged" SME networks.

You'd pass control on "what should go where?" from the host to the router, 
but given that hosts are not there yet, that will get the job done.

Gert Doering
        -- NetMaster

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 22 Mar 2022 16:36:48 +0000

Hi Jordi,
NPT is not NAT – it is not a so big problem for applications (stateless, even connection could be initiated 2 way).
Meanwhile, it is possible to think about a better solution.
Eduard
From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
Sent: Tuesday, March 22, 2022 5:55 PM
To: [email-masked]
Subject: Re: [v6ops] Thoughts about wider operational input

Hi Eduard,

Regards,
Jordi
@jordipalet

El 22/3/22, 13:04, "v6ops en nombre de Vasilenko Eduard" <[email-masked]<mailto:[email-masked]> en nombre de vasilenko.eduard=[email-masked]<mailto:[email-masked]>> escribió:

Hi Jordi,

Eduard
From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
Sent: Tuesday, March 22, 2022 12:34 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] Thoughts about wider operational input

Regards,
Jordi
@jordipalet

Regards,
Jordi
@jordipalet

    Hi,

    What is "an enterprise"?

    Gert Doering
            -- NetMaster

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 22 Mar 2022 16:40:27 +0000

Because parameters on the uplink
Are not coordinated with ND on the LAN interface.
We propose how to fix it https://datatracker.ietf.org/doc/html/draft-vv-6man-nd-prefix-robustness-02
but nobody is interested.

If Uplink would get a different prefix after 3GPP reconnecting - the host would use the old prefix for up to 1 week (probably 1/2 of the week).

Eduard
-----Original Message-----
From: Gert Doering [mailto:[email-masked]] 
Sent: Tuesday, March 22, 2022 6:14 PM
To: Vasilenko Eduard <[email-masked]>
Cc: Gert Doering <[email-masked]>; JORDI PALET MARTINEZ <jordi.palet=[email-masked]>; [email-masked]
Subject: Re: [v6ops] Thoughts about wider operational input

Hi,

So why would any sane vendor produce 3GPP routers that send a prefix lifetime of 1 week?

This is not a new discussion, it's a well-understood issue, and it is addressed in, for example, RFC8978, RFC9096 and draft-ietf-6man-slaac-renum

Gert Doering
        -- NetMaster

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 22 Mar 2022 16:41:41 +0000

Agree.
Just the problem of HNCP adoption.
Ed/
-----Original Message-----
From: Gert Doering [mailto:[email-masked]] 
Sent: Tuesday, March 22, 2022 6:15 PM
To: Vasilenko Eduard <[email-masked]>
Cc: Gert Doering <[email-masked]>; Ted Lemon <[email-masked]>; [email-masked]; JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
Subject: Re: [v6ops] Thoughts about wider operational input

Hi,

"Buy two routers, plug them together in an arbitrary fashion, get multihoming".

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Tue, 22 Mar 2022 17:42:14 +0100

Hi,

> If Uplink would get a different prefix after 3GPP reconnecting - the host would use the old prefix for up to 1 week (probably 1/2 of the week).

This is purely a question of RA parameters used by the LTE router
towards the LAN.

Gert Doering
        -- NetMaster

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 22 Mar 2022 17:44:21 +0100

I don’t think app developers will agree with you.

I will re-read anyway NPT RFC, I recall it has a specific warning section on that … and anyway, it is an experimental protocol.

Saludos,

Jordi

@jordipalet

El 22/3/22, 17:37, "v6ops en nombre de Vasilenko Eduard" <[email-masked] en nombre de vasilenko.eduard=[email-masked]> escribió:

Hi Jordi,

Eduard

Hi Eduard,

Regards,

Jordi

@jordipalet

Hi Jordi,

They would be happy.

Eduard

Regards,

Jordi

@jordipalet

Regards,
Jordi
@jordipalet

    Hi,

    What is "an enterprise"?

    Gert Doering
            -- NetMaster

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 22 Mar 2022 16:44:38 +0000

This is very right.
If the decision point is on the host then it is possible to play with the policy on what to use.
Section 5.1 is about "equal prefixes" and "non-equal prefixes": https://datatracker.ietf.org/doc/html/draft-vv-6man-nd-prefix-robustness-02#page-13
Ed/
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Gert Doering
Sent: Tuesday, March 22, 2022 6:21 PM
To: Toerless Eckert <[email-masked]>
Cc: [email-masked]; JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
Subject: Re: [v6ops] Thoughts about wider operational input

Hi,

On Tue, Mar 22, 2022 at 11:41:19AM +0100, Toerless Eckert wrote:
> Why would it not be a desirable feature for me as the end-user to have 
> an IPv6/IPv6 NAT on the router towards the 3 Internet connections to 
> which i multi-home ? Sure, we can probably list some downsides, but 
> they need to be weighted against the benefits for me as an end user. Not ?

The reason why I prefer "host has multiple GUAs" better, in theory, is that it gives the *user* more control on what he wants - like, "I can run my bittorrent via the cable ISP, and SSH out via LTE", by selecting the corresponding source IP = selecting the outgoing ISP.

Now, in practice, source address selection for "there are multiple GUAs with different pros/cons attached" is lacking quite a bit.  And HNCP routers with source-based forwarding can not be bought.  So all the nice things do not work.

Which means, "a router with GUAs inside, a DSL port and a LTE modem and
NPT66 on both outside interfaces" is a really nice redundancy solution for basically all "mostly unmanaged" SME networks.

You'd pass control on "what should go where?" from the host to the router, but given that hosts are not there yet, that will get the job done.

Gert Doering
        -- NetMaster

---

From: Nick Buraglio <[email-masked]>
Date: Tue, 22 Mar 2022 11:44:53 -0500

Multihoming is just one piece of a much larger impediment apparatus.
Barrier of entry is the umbrella, and it is exacerbated by lack of support
across the board on common, modern - and in some cases brand new platforms.
Even if we're talking about dual stack, which as much as I hate to admit,
is probably the only viable path forward for most environments, the support
for IPv6 is haphazard and inconsistent in very common applications and
operating environments (take docker, for example).

I think a question we should be asking is not only "How can we make
operators /want/ to deploy IPv6?" but also "How can IPv6 be elevated to at
least a peer in software and product development". Perhaps this is just an
artifact of "squatters rights", but in my day-to-day, I almost never see
software of product development embrace IPv6 as the first pass protocol.
This may not sound that important, but what it implies and perpetuates is
two fold:

It promotes the idea that IPv4 is the "default", and that IPv6 is an
afterthought.
It very clearly states that IPv6 is not a requirement.

Operating systems managed to get the prioritization in place. How can that
"IPv6 by default" or even better - protocol agnostic mentality - take the
next step up the trail into product and software development?  Again, I
really don't see this as a technical problem, per se, but perhaps some
official best practices for activities such as:

"Software development protocol best practices"
"Product development protocol best practices"

nb

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 22 Mar 2022 16:47:31 +0000

> This is purely a question of RA parameters used by the LTE router towards the LAN.

No. It is not possible to achieve fast convergence by timers.
The current preferred timer is especially big by default,
But it is not possible to put it small enough.
ND protocol change is needed.

Ed/
-----Original Message-----
From: Gert Doering [mailto:[email-masked]] 
Sent: Tuesday, March 22, 2022 7:42 PM
To: Vasilenko Eduard <[email-masked]>
Cc: Gert Doering <[email-masked]>; JORDI PALET MARTINEZ <jordi.palet=[email-masked]>; [email-masked]
Subject: Re: [v6ops] Thoughts about wider operational input

Hi,

> If Uplink would get a different prefix after 3GPP reconnecting - the host would use the old prefix for up to 1 week (probably 1/2 of the week).

This is purely a question of RA parameters used by the LTE router towards the LAN.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Tue, 22 Mar 2022 17:48:18 +0100

Hi,

On Tue, Mar 22, 2022 at 05:44:21PM +0100, JORDI PALET MARTINEZ wrote:
> I don???t think app developers will agree with you.

Apps today are "https to cloud" anyway, which is very NAT friendly.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Tue, 22 Mar 2022 17:52:07 +0100

Hi,

> ND protocol change is needed.

There is nothing in ND protocol that prevents setting timers lower than
1 week.  Nothing.

"Big by default" is a pure implementation decision in your LTE router - 
it could be announcing "12hour" instead of "1 week", and would be perfectly
in line with ND standard.

Prefix depreciation by announcing "preferred lifetime = 0" works.

Please read the documents I've referenced.

Gert Doering
        -- NetMaster

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 22 Mar 2022 16:52:04 +0000

Experimental is just a label. Change it if it is the only problem.

Yes, maybe some protocol would embed the IP address, extremely rare.
UDP/TCP ports are not touched.

NPT+ULA is “low hanging fruit” in business consultants' terminology.
It does not preclude developing something better.
Because as Gert said: it is better to have a policy on what Carrier to use for what type of traffic.

From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
Sent: Tuesday, March 22, 2022 7:44 PM
To: [email-masked]
Subject: Re: [v6ops] Thoughts about wider operational input

Saludos,
Jordi
@jordipalet

El 22/3/22, 17:37, "v6ops en nombre de Vasilenko Eduard" <[email-masked]<mailto:[email-masked]> en nombre de vasilenko.eduard=[email-masked]<mailto:[email-masked]>> escribió:

Hi Jordi,

Hi Eduard,

Regards,
Jordi
@jordipalet

Hi Jordi,

Eduard

Regards,
Jordi
@jordipalet

Regards,
Jordi
@jordipalet

    Hi,

    What is "an enterprise"?

    Gert Doering
            -- NetMaster

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 22 Mar 2022 16:58:22 +0000

Subscribers tend to fix everything by reloading.
CPE would not know what to deprecate after the reload.
Even 15min for a preferred lifetime is not a good solution (telephony had 50ms in 1970),
Less than 15min would be risky for some environments.

"Flash renumbering" should not be resolved by timers. It should be logic of events that would be much faster.
https://datatracker.ietf.org/doc/html/draft-vv-6man-nd-prefix-robustness-02

Ed/
-----Original Message-----
From: Gert Doering [mailto:[email-masked]] 
Sent: Tuesday, March 22, 2022 7:52 PM
To: Vasilenko Eduard <[email-masked]>
Cc: Gert Doering <[email-masked]>; JORDI PALET MARTINEZ <jordi.palet=[email-masked]>; [email-masked]
Subject: Re: [v6ops] Thoughts about wider operational input

Hi,

On Tue, Mar 22, 2022 at 04:47:31PM +0000, Vasilenko Eduard wrote:
> The current preferred timer is especially big by default, But it is 
> not possible to put it small enough.

"Big by default" is a pure implementation decision in your LTE router - it could be announcing "12hour" instead of "1 week", and would be perfectly in line with ND standard.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Tue, 22 Mar 2022 18:07:30 +0100

Hi,

> Less than 15min would be risky for some environments.

Please do read the references I've sent you.  It helps against repeating
the same old "it cannot be done" arguments again and again.

(I do note that you are now talking about "15 min", while it was "1 week"
before)

Gert Doering
        -- NetMaster

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 22 Mar 2022 18:07:42 +0100

Which is a very big trouble, especially for IoT. If the cloud is down, you can't access your own devices even if you're at home. Crazy!

Even worst. If the cloud of the device vendor, or the cloud itself, goes to bankrupt, you throw away all those devices ..., never mind how much money you spend on that - times number of customers of those devices ...

Of course, this is a very different topic, and only possible solution is probably regulation. If you want to sell in the EU, you must publish an open API so in case you "fail", open source or third parties can develop solution to avoid so much waste.

Anyway, there are other apps that don't work or will work with clouds.
 
Regards,
Jordi
@jordipalet

El 22/3/22, 17:49, "Gert Doering" <[email-masked]> escribió:

    Hi,

    Gert Doering
            -- NetMaster

---

From: Simon <[email-masked]>
Date: Tue, 22 Mar 2022 17:47:32 +0000

> But unfortunately the usual reply is to repeat that we were idiots not to make IPv6 backwards-compatible (often accompanied by one of the many ideas proposed but found impossible in the early 1990s…

I’m one of those IPv6 supporters (under my real name !) - and often get the usual responses. Funnily enough, every time I’ve challenged someone to state how they would add address bits to IPv4 without breaking compatibility with *everything*, I never get an answer though I generally get a load of downvotes !
I also get plenty of responses (and downvotes) telling me I’m wrong and that NAT doesn’t break anything at all.

> the corresponding source IP = selecting the outgoing ISP.

Flipping that around, what if there are good business reasons to route certain traffic via certain routes ? Users will always pick what “works best for them” and ignore any instructions they are given - and not to mention most IoT stuff probably won’t even offer any options in that regard.
One upside (and I think it’s the only upside) of NAT is that the network admin can set the policy of which traffic uses which link - so, for example, routing some traffic via a fast link and other traffic via a cheap link; or just routing certain traffic via one link to avoid contention with other traffic (a common way to make VoIP work reliably in the presence of not-unlimited-bandwidth links).
That’s not to say I’m any fan of NAT - but IMO that is one area where it does actually have a benefit.

> Apps today are "https to cloud" anyway, which is very NAT friendly.

Which as Jordi points out, is a big problem.
Apart from the “vendor has turned off the infrastructure, you now own a pile of door stops” issue (ask Revolv owners how that works out), it’s putting the internet under the control of fewer and fewer larger and larger organisations. We’re already a long way down the road to never actually owning anything we’ve bought, and that’s a bad thing.

But IMO one of the big reasons why users have accepted it without question is that there are too many roadblocks (configuring NAT being one of them) for the average users to do some of the remote access stuff that the IoT stuff is bought for.

I doubt that anyone other than niche vendors are going to do anything that reduces vendor control - or worse, allow a user to decide for themselves how something should work and be used.

Simon

---

From: Nick Buraglio <[email-masked]>
Date: Tue, 22 Mar 2022 12:51:39 -0500

The issue with ULA + NPT is that if there is an A record, ULA + translation
will rarely if ever be used unless the application dictates it as the ULA
addressing is de-prioritized in nearly every operating system - but that's
a very specific technical implementation issue and I don't believe that it
is fundamental to the lack of enterprise deployment.

nb

On Tue, Mar 22, 2022 at 11:53 AM Vasilenko Eduard <vasilenko.eduard=
[email-masked]> wrote:

> *From:* v6ops [mailto:[email-masked]] *On Behalf Of *JORDI PALET
> MARTINEZ
> *Sent:* Tuesday, March 22, 2022 7:44 PM
> *To:* [email-masked]
> *Subject:* Re: [v6ops] Thoughts about wider operational input
>
>
>
> I will re-read anyway NPT RFC, I recall it has a specific warning section
> on that … and anyway, it is an experimental protocol.
>
>
>
>
>
>
>
> Saludos,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 22/3/22, 17:37, "v6ops en nombre de Vasilenko Eduard" <
> [email-masked] en nombre de vasilenko.eduard=
> [email-masked]> escribió:
>
>
>
> Hi Jordi,
>
> NPT is not NAT – it is not a so big problem for applications (stateless,
> even connection could be initiated 2 way).
>
> *From:* v6ops [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *JORDI PALET MARTINEZ
> *Sent:* Tuesday, March 22, 2022 5:55 PM
> *To:* [email-masked]
> *Subject:* Re: [v6ops] Thoughts about wider operational input
>
>
>
> Hi Eduard,
>
>
>
> El 22/3/22, 13:04, "v6ops en nombre de Vasilenko Eduard" <
> [email-masked] en nombre de vasilenko.eduard=
> [email-masked]> escribió:
>
>
>
> Hi Jordi,
>
>
>
> *From:* v6ops [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *JORDI PALET MARTINEZ
> *Sent:* Tuesday, March 22, 2022 12:34 PM
> *To:* [email-masked]
> *Subject:* Re: [v6ops] Thoughts about wider operational input
>
>
>
> 2.      I think in the future almost every site could want to be
> multihomed, in some cases “n” links active, many other cases just as a
> backup.
>
> Only if we solve this, organizations could learn that NAT with IPv6 is not
> the solution, but something better that provides the same results, and no
> need to have “private” addresses, because the way NAT is offering a
> “different” addressing inside and outside is not NAT per-se, but statefull
> firewalling.
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Gert Doering <[email-masked]>
Date: Tue, 22 Mar 2022 19:34:15 +0100

Hi,

On Tue, Mar 22, 2022 at 05:47:32PM +0000, Simon wrote:
> Flipping that around, what if there are good business reasons to
> route certain traffic via certain routes ? Users will always pick
> what ???works best for them??? and ignore any instructions they are
> given - and not to mention most IoT stuff probably won???t even
> offer any options in that regard.

This is "Home" vs. "SoHo" vs. "more enterprisey" networks.

In a home network, and to some extent also "very small company" networks,
there is usually nobody who does the "good business reasons to configure
a router in a certain way" - so, having these controls on the users's PC
sounds like a great thing.

In a slightly more actively managed, I agree with you, these controls
move towards the network edge, namely "the router".

> One upside (and I think it???s the only upside) of NAT is that the network admin can set the policy of which traffic uses which link - so, for example, routing some traffic via a fast link and other traffic via a cheap link; or just routing certain traffic via one link to avoid contention with other traffic (a common way to make VoIP work reliably in the presence of not-unlimited-bandwidth links).

Agree.

> That???s not to say I???m any fan of NAT - but IMO that is one area where it does actually have a benefit.

Nasty remarks aside, I find NAT (NPT66) a useful tool.

Having NAT forced on me (carrier-grade IPv4 NAT style) is not what I like.

Gert Doering
        -- NetMaster

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Mar 2022 08:54:47 +1300

Hi Gert,

I see that the discussion has been going on while I was sleeping, but I want to clarify below...
> are probably way less than 10 million...

I came up with 10 million quite some years ago as a reasonable estimate
of the number of medium to large businesses in the world, all of which
might depend on *reliable* Internet access to survive (and WfH during
COVID has made this even more important recently). So all of them
should have two independent paths to the Internet to assure reliability.
That means two different ISPs (or less good, two completely independent
paths to the same ISP).

So, if PI addressing is the answer, that really does take us to
10M /48s to be routed.

If PA is the answer, that's why I worked on SHIM6 (may it rest in
peace). Which is why I worked on RFC 8028. If that's not the
answer, we're back to NPTv6. Possibly even to ULA+NPTv6.

> you get, what is the cost, which of the variants do you want, and why...?"

Yes.
    Brian

---

From: Nick Buraglio <[email-masked]>
Date: Tue, 22 Mar 2022 15:12:20 -0500

ULA is an operational non-starter in the presence of any dual stacked
hosts.  Per its design, it just won't ever use IPv6 in any meaningful way
and that time and effort are better served on adding GUA addressing of one
kind or another.

nb

On Tue, Mar 22, 2022 at 2:55 PM Brian E Carpenter <
[email-masked]> wrote:

> >> I agree with Jordi that multihoming is a genuine impediment. What isn't
> generally realised is that it's a problem of scale when considering at
> least 10,000,000 enterprises, much more than it's a problem of IPv6 itself.
> >
> > What is "an enterprise"?
> >

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Mar 2022 21:20:18 +0100

I'm sure you believe this assertion, Nick, but you haven't given us any way
of understanding why you believe this. In fact we're using ULAs in the
Thread Border Router to enable IPv6 communication between different
subnets, which literally could not be done with IPv4. So at least for this
use case, ULAs work well. Would it work better to have a GUA? Comme ci
comme ça. On the one hand, prefix delegation and real routing would make
the solution more general. On the other, GUAs are great for reaching out to
the internet, which we may or may not want light bulbs to be able to do.

---

From: Nick Buraglio <[email-masked]>
Date: Tue, 22 Mar 2022 15:35:08 -0500

Yes, I know I have harped on this many times and have posted some
simple examples of the behavior to the list. My experience has been, and
continues to be, that if I have dual stacked hosts with A and AAAA records,
and the IPv6 clients are using ULA that IPv6 is never used. In an IPv6-only
environment ULA has no higher priority protocol to supersede the ULA. In
the context of transitioning to an IPv6 world, it is fairly unrealistic to
assume any kind of greenfield, and dual-stack is by and large the standard
"permanently temporary" solution for the vast majority of implementations.
So in this context, which has been 99% of what I have seen until I began
working on the IPv6-only implementation mandated by the USG OMB-M-21-07
document, that was the de facto standard (and will continue to be for
enterprise deployments, in my opinion).
I would be happy to be incorrect about this, honestly it would make my
work-life easier if I was. So, yes, I fully acknowledge that your use case
is absolutely the right one for ULA. For doing a transition in an existing
network (which circles back the the original topic of this thread: getting
enterprises to use IPv6 in a meaningful way), this is a really well put
together descriptions of the every-day implications of trying to use ULA:
https://blogs.infoblox.com/ipv6-coe/ula-is-broken-in-dual-stack-networks/

nb

On Tue, Mar 22, 2022 at 3:20 PM Ted Lemon <[email-masked]> wrote:

> I'm sure you believe this assertion, Nick, but you haven't given us any
> way of understanding why you believe this. In fact we're using ULAs in the

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Mar 2022 09:48:12 +1300

Nick,

Where is the "prefer IPv4 over ULA" preference coded (whereas, presumably, "prefer IPv4 over GUA" is not coded)?

Regards
    Brian Carpenter

On 23-Mar-22 09:35, Nick Buraglio wrote:
> Yes, I know I have harped on this many times and have posted some simple examples of the behavior to the list. My experience has been, and continues to be, that if I have dual stacked hosts with A and AAAA records, and the IPv6 clients are using ULA that IPv6 is never used. In an IPv6-only environment ULA has no higher priority protocol to supersede the ULA. In the context of transitioning to an IPv6 world, it is fairly unrealistic to assume any kind of greenfield, and dual-stack 
is by and large the standard "permanently temporary" solution for the vast majority of implementations. So in this context, which has been 99% of what I have seen until I began working on the IPv6-only implementation mandated by the USG OMB-M-21-07 document, that was the de facto standard (and will continue to be for enterprise deployments, in my opinion).
> I would be happy to be incorrect about this, honestly it would make my work-life easier if I was. So, yes, I fully acknowledge that your use case is absolutely the right one for ULA. For doing a transition in an existing network (which circles back the the original topic of this thread: getting enterprises to use IPv6 in a meaningful way), this is a really 
well put together descriptions of the every-day implications of trying to use ULA:
> https://blogs.infoblox.com/ipv6-coe/ula-is-broken-in-dual-stack-networks/ <https://blogs.infoblox.com/ipv6-coe/ula-is-broken-in-dual-stack-networks/>
> 
> nb
> 
> 
> 
> 
> 
> On Tue, Mar 22, 2022 at 3:20 PM Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     I'm sure you believe this assertion, Nick, but you haven't given us 
any way of understanding why you believe this. In fact we're using ULAs in the Thread Border Router to enable IPv6 communication between different 
subnets, which literally could not be done with IPv4. So at least for this use case, ULAs work well. Would it work better to have a GUA? Comme ci comme ça. On the one hand, prefix delegation and real routing would make the solution more general. On the other, GUAs are great for reaching 
out to the internet, which we may or may not want light bulbs to be able to do.
> 
>     On Tue, Mar 22, 2022 at 9:13 PM Nick Buraglio <[email-masked] <mailto:[email-masked]>> wrote:
> 
>         ULA is an operational non-starter in the presence of any dual stacked hosts.  Per its design, it just won't ever use IPv6 in any meaningful way and that time and effort are better served on adding GUA addressing of one kind or another.
> 
>         nb
> 
> 
> 
>         On Tue, Mar 22, 2022 at 2:55 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>             Hi Gert,
> 
>             [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: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Mar 2022 09:51:32 +1300

Hi Toerless,
> DNS names work well enough in practice.

What are you saying? That it's too hard to add AAAA records, or that
IoT stacks can't deal with multiple AAAA replies?

    Brian

>> I believe in the homes, deployment is not a problem at the time being - CPEs with IPv6 are being provided by the ISPs that want to turn it on. The problem in enterprises is, most of of the cases, because, they didn't 
entered the proper "learning cycle for IPv6" (no need for it, no incentives, troubles if we don't have NAT, multihoming, etc.), so there is no request from IT to the managers and then there is no budget. Of course, there are exceptions, but I see this everyday specially in countries where the government mandated IPv6 in the public administration.
>>      > Only if we solve this, organizations could learn that NAT with IPv6 is not the solution, but something better that provides the same results, and no need to have “private” addresses, because the way NAT is offering a “different” addressing inside and 
outside is not NAT per-se, but statefull firewalling.
>>      > Is it really hncp that we needed here?  I think the key tech we 
need is source-address-based forwarding, and babel i think has delivered that. Granted, getting that into soho routers is a problem.
>>      > Maybe the terminology is not the most appropriate and we should 
talk about "organizations", because there are many types of networks that 
have the same problem and those are not enterprises (such as government sites, NGOs, etc.).
>>      > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of 
the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
>>      > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of 
the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and 
will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must 
reply to the original sender to inform about this communication and delete it.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Mar 2022 22:03:35 +0100

Oh, now that's really interesting. I'm glad I asked the clarifying
question. So when you have a host with a ULA, it doesn't try to do NAT64 I
guess because it thinks it needs a GUA to do that?

---

From: Nick Buraglio <[email-masked]>
Date: Tue, 22 Mar 2022 16:04:50 -0500

In RFC6724 section 2.1 states:

If an implementation is not configurable or has not been configured,
then it SHOULD operate according to the algorithms specified here in
conjunction with the following default policy table:

      Prefix        Precedence Label
      ::1/128               50     0
      ::/0                  40     1
      ::ffff:0:0/96         35     4
      2002::/16             30     2
      2001::/32              5     5
      fc00::/7               3    13
      ::/96                  1     3
      fec0::/10              1    11
      3ffe::/16              1    12

https://datatracker.ietf.org/doc/html/rfc6724#section-2.1

Linux is /theoretically/ configurable but implementations are
inconsistent. Even so, changing this at scale is operationally
impossible and would present as a huge impediment for any deployment
of size. My experience has been that most implementations have taken
the "...implementation is not configurable" approach, and that has
become the de facto standard. Again, if we are talking about
impediments to enterprise deployment, this is on the list. It is
unrealistic to expect or require a sweeping change to a protocol
default by a random enterprise deployment team. We went quite deep in
this thread back in August of 2021 on this list. I am also happy to be
wrong here.

nb

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Mar 2022 22:09:21 +0100

Okay, but what does that have to do with ULAs and NAT64?

On Tue, Mar 22, 2022 at 10:05 PM Nick Buraglio <[email-masked]> wrote:

> > Where is the "prefer IPv4 over ULA" preference coded (whereas,
> presumably, "prefer IPv4 over GUA" is not coded)?
> >
> > Regards
> >     Brian Carpenter
> >
> assume any kind of greenfield, and dual-stack
> > is by and large the standard "permanently temporary" solution for the
> vast majority of implementations. So in this context, which has been 99% of
> what I have seen until I began working on the IPv6-only implementation
> mandated by the USG OMB-M-21-07 document, that was the de facto standard
> (and will continue to be for enterprise deployments, in my opinion).
> enterprises to use IPv6 in a meaningful way), this is a really
> <https://blogs.infoblox.com/ipv6-coe/ula-is-broken-in-dual-stack-networks/
> >
> > >
> > > nb
> > >
> > >
> > >
> > >
> > >
> > any way of understanding why you believe this. In fact we're using ULAs
> in the Thread Border Router to enable IPv6 communication between different
> > subnets, which literally could not be done with IPv4. So at least for
> this use case, ULAs work well. Would it work better to have a GUA? Comme ci
> the solution more general. On the other, GUAs are great for reaching
> > >         ULA is an operational non-starter in the presence of any dual
> stacked hosts.  Per its design, it just won't ever use IPv6 in any
> meaningful way and that time and effort are better served on adding GUA
> addressing of one kind or another.
> > >
> > >         nb
> > >
> > >
> > >
> [email-masked] <mailto:[email-masked]>> wrote:
> > >
> > >             Hi Gert,
> > >
> > >              >> I agree with Jordi that multihoming is a genuine
> impediment. What isn't generally realised is that it's a problem of scale
> when considering at least 10,000,000 enterprises, much more than it's a
> problem of IPv6 itself.
> > >              >
> > >              > What is "an enterprise"?
> > >              >
> > >             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: Nick Buraglio <[email-masked]>
Date: Tue, 22 Mar 2022 16:32:31 -0500

NAT64? Nothing. It's specifically problematic for dual stacked
networks. NAT64 implies that hosts are IPv6-only, which has its own
unique details.

nb

---

From: Gert Doering <[email-masked]>
Date: Tue, 22 Mar 2022 22:34:24 +0100

Hi,

> hosts.  Per its design, it just won't ever use IPv6 in any meaningful way

That's just an entry in the gai.conf table, not something unfixable by
protocol design.

> and that time and effort are better served on adding GUA addressing of one

So how does your solution to "multihoming for 10 million enterprises"
look like, which is less work than fixing ULA preferences?

Gert Doering
        -- NetMaster

---

From: Nick Buraglio <[email-masked]>
Date: Tue, 22 Mar 2022 16:50:19 -0500

Sure, I can edit the gai.conf table on a handful of systems, I may
even be able to write some ansible/puppet/chef/cfengine to do that
across 10,000 linux systems, or modify the windows preference using a
policy. That is not solvable in a way (at least that I am aware of) on
something like 5000 iPads or 5000 IP cameras, so we're back to extra
overhead, which translates into person hours, which translates into a
cost center with no cost benefit. What we're talking about is not "is
it technically feasible". It's a barrier of entry. These things make
deployment harder. I see this literally every day in operations and
migration to IPv6.
I don't want to conflate what I am talking about with multihoming.
Multihoming is a different issue that is only tangentially related if
we talk about ULA as an analog for 1918 space and use some kind of
translation, but again, how does that work for IoT devices that have a
non-modifiable preference table, or that have an application that has
its own ULA standard set? It is unrealistic to think that this would
work  for guest systems in dual stacked mode, or BYOD devices at any
scale, either. "You need to edit this obscure default file on your
system" or "run this application that we wrote to change a default to
get on our network" is not going to be a good strategy.

nb

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Mar 2022 11:41:21 +1300

Nick,

I'm familiar with RFC6724. It says this:

"  Another effect of the default policy table is to prefer
    communication using IPv6 addresses to communication using IPv4
    addresses, if matching source addresses are available."

That seems to be incorrect. To make it true, the entry should be

  fc00::/7              39    13

if I have that right. That would still give precedence to GUAs
if available. 41 would give precedence to ULAs.

Regards
    Brian Carpenter

On 23-Mar-22 10:04, Nick Buraglio wrote:
>> is by and large the standard "permanently temporary" solution for the vast majority of implementations. So in this context, which has been 99% of what I have seen until I began working on the IPv6-only implementation 
mandated by the USG OMB-M-21-07 document, that was the de facto standard (and will continue to be for enterprise deployments, in my opinion).

---

From: Chongfeng Xie <[email-masked]>
Date: Wed, 23 Mar 2022 09:56:22 +0800

I think the problem is that there is a gap between enterprises and what IETF is doing, generally, enterprise needs a solution which may consist of multiple technologies, to update their network or system,  but IETF produces many relatively scattered technologies in the form of standards or informational documents.  These standards may be systematically organized in IETF,  but they are not equal to solutions for enterprise, sometimes they touch a specific requirement of enterprise, but in most cases they don’t. In order to attract the participation of enterprises, it is better to arrange the technologies from the perspective and tell the enterprises what advantages IPv6 can bring to them and how to upgrade their network with IPv6. If they feel the output of IETF is close to their network, information system or production, they will have interest to join.

Best regards
Chongfeng

> 2022年3月22日 上午4:33，Fred Baker <[email-masked]> 写道：
>

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 22 Mar 2022 22:40:25 -0400

Private address space, NAT and web proxy really eliminates the business
justification for enterprises to go through all the effort for all the
training and learning curve to migrate to IPv6.

How do you justify if everything works fine and if it’s not broken why fix
it mantra.  That goes for even companies in the IT business.

For business that ever need access to v6 internet content it’s easy to
setup a 4to6 web proxy and can still keep the corporate intranet IPv4.
Even when the all web content is 100% IPv6 enterprises can still utilize
their 4to6 proxy and stay indefinitely IPv4.

That gap is very difficult to close and I guess really the only way is when
router and switch vendors stop supporting IPv4 the time will finally come
for enterprises to finally migrate to IPv6.

I think for numbers counting for IPV6 penetration I think it makes sense to
exclude enterprises from the numbers as it’s an unknown.  I don’t think
it’s counted anyway.  The main concern should be web content penetration
with IPV6 and getting that to ramp up to the eventual 100% of all web
content being on IPv6.

Enterprises need real business drivers and justification to migrate to IPv6
or its never going to happen unless it impacts their bottom line.

For corporations that do business with the government in the US and maybe
other countries have a mandate that the corporations must have IPv6
deployed and use IPv6.

Another business justification is M&A activity for large enterprises and
complex NAT solutions and elimination of NAT as a business justification to
migrate to IPv6.

Kind Regards

Gyan

On Tue, Mar 22, 2022 at 9:57 PM Chongfeng Xie <[email-masked]>
wrote:

> I think the problem is that there is a gap between enterprises and what
> IETF is doing, generally, enterprise needs a solution which may consist of
> multiple technologies, to update their network or system,  but IETF
> produces many relatively scattered technologies in the form of standards or
> informational documents.  These standards may be systematically organized
> in IETF,  but they are not equal to solutions for enterprise, sometimes
> they touch a specific requirement of enterprise, but in most cases they
> don’t. In order to attract the participation of enterprises, it is better
> to arrange the technologies from the perspective and tell the enterprises
> what advantages IPv6 can bring to them and how to upgrade their network
> with IPv6. If they feel the output of IETF is close to their network,
> information system or production, they will have interest to join.
>
> Best regards
> Chongfeng
>
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Joe Maimon <[email-masked]>
Date: Wed, 23 Mar 2022 00:40:40 -0400

Gyan Mishra wrote:
>
> For corporations that do business with the government in the US and 
> maybe other countries have a mandate that the corporations must have 
> IPv6 deployed and use IPv6.
I cant say I am a fan of gov mandates for how an entity runs its 
internal network so long as government data and/or communications that 
may be on it is secured and reliably so, which is a legitimate interest 
pertaining directly to their business relationship. Other than that, its 
an artificial orthogonal agenda driven mandate and while we may be a fan 
of the particular goal in this case, it should not legitimize the 
overreach inherent in the approach.

Also it breeds resentment and checkboxing.

>
> Another business justification is M&A activity for large enterprises 
> and complex NAT solutions and elimination of NAT as a business 
> justification to migrate to IPv6.

They are going to want PI or registered ULA for that.

How do you suppose the M&A driver works? Is the network engineered to be 
dual stacked so that future M&A integration will be much easier if you 
just skip the IPv4 part? Or just build the network v6 only because an 
M&A might happen and your might land on top and then it might be a big 
win? Or an M&A actually happens and internal communications are now a 
business goal so deploying v6 across both entire networks and redoing 
those internal communications on v6 is a better effort than the other 
approaches they have been coping with in the v4 world for decades now?

M&A might be an enterprise driver but its hardly clear cut.

And in general, I personally doubt that by and large enterprises would 
view elimination of NAT as a feature. Perhaps they may want the ability 
to selectively disable NAT or "unhide" selected internal addresses and 
IPv6 will enable that, but many view the obfuscation and abstraction NAT 
provides as a feature, and not even a security one at that.

At a certain size, they just want more bits than rfc1918 offers.

>
>
>
> Kind Regards
>
> Gyan
>
>
>
> On Tue, Mar 22, 2022 at 9:57 PM Chongfeng Xie <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I think the problem is that there is a gap between enterprises and
>     what IETF is doing, generally, enterprise needs a solution which
>     may consist of multiple technologies, to update their network or
>     system,  but IETF produces many relatively scattered technologies
>     in the form of standards or informational documents.  These
>     standards may be systematically organized in IETF,  but they are
>     not equal to solutions for enterprise, sometimes they touch a
>     specific requirement of enterprise, but in most cases they don’t.
>     In order to attract the participation of enterprises, it is better
>     to arrange the technologies from the perspective and tell the
>     enterprises what advantages IPv6 can bring to them and how to
>     upgrade their network with IPv6. If they feel the output of IETF
>     is close to their network, information system or production, they
>     will have interest to join.
>
>     Best regards
>     Chongfeng
>
>
>
>
>>     2022年3月22日 上午4:33，Fred Baker <[email-masked]
>>     <mailto:[email-masked]>> 写道：
>>
>>     I have thought some about the discussion we had in the V6ops
>>     meeting about increasing operational input. Several suggestions
>>     were made: add a separate meeting, segregate parts of the
>>     meeting, attend the IEPG, use an interim, and so on. One thought
>>     that I had was to schedule a meeting at RIPE in May.
>>
>>     None of these address what seems to me to be a core problem: ISPs
>>     are deploying, but enterprise isn’t. How do we get enterprise on
>>     board?
>>
> /Network Solutions A//rchitect /
>
> /Email [email-masked] <mailto:[email-masked]>//
> /
>
> /M 301 502-1347
>
> /
>
>
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 23 Mar 2022 01:31:55 -0400

Hi Joe

> Also it breeds resentment and checkboxing.

   Gyan> Agreed

> M&A might be an enterprise driver but its hardly clear cut.

    Gyan> Completely agree.

> provides as a feature, and not even a security one at that.

    Gyan> This is really special use cases for larger enterprises that are
constantly buying companies and have constant issues with overlap of space
and have to continue to propagate and expand NAT followed by OPEX costs to
readdress.   The idea is that if you migrate to IPv6 Only enterprise wide
you can eliminate Nat.

*Gyan Mishra*

*M 301 502-1347*

---

From: Gert Doering <[email-masked]>
Date: Wed, 23 Mar 2022 06:54:34 +0100

Hi,

On Tue, Mar 22, 2022 at 04:50:19PM -0500, Nick Buraglio wrote:
> Sure, I can edit the gai.conf table on a handful of systems, 

This is not what I had in mind.  If "we" decide that ULA is a good
way forward, IETF can update RFCs, and vendors will eventually
update their base OS.  It might take 5 years, but so will everything
else in Big Enterprise land.

And yes, your Cameras will never get an update - but I do not see them
in a dual-stacked network anyway, and they have no CLAT, so their
preference is not relevant.  It will have to use what is there.

(Dual-stack cannot be the answer anyway - it will have all the issues
of IPv4, plus the added complications of dual-stack.  Services need to
be dual-stack, but for all the rest, single-stack IPv6 needs to be
the end goal - see facebook etc)

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Wed, 23 Mar 2022 06:57:32 +0100

Hi,

On Tue, Mar 22, 2022 at 10:40:25PM -0400, Gyan Mishra wrote:
> How do you justify if everything works fine and if it???s not broken why fix

Real Enterprise Networks are never "everything works fine", but usually
a horrible mess of internal NAT44, sometimes multiple layers.

I've been told by one enterprise customer that it sometimes takes them
2 weeks to troubleshoot "host A cannot reach host B" problems, because
of "nobody knows which addresses host A and host B should have, in network 
parts X, Y and Z, so it needs 5 different teams to debug this".

What is still missing is the understanding "the mess of grown bandaid-NAT
goes away with IPv6".

Gert Doering
        -- NetMaster

---

From: hsyu <[email-masked]>
Date: Wed, 23 Mar 2022 16:36:54 +0800

Hi,

I think it is necessary to promote the migration of ipv4 to ipv6 from the aspects of persuading the decision makers of the enterprise and providing training, as follows:
1. More communication with decision makers. Inform decision makers that the migration from IPv4 to IPv6 can be disruptive, and if not prepared early, there will be many uncertain hidden dangers later. From the perspective of revenue, after migrating to IPv6, many ipv4 address assets can be released and realized, and these IPv4 address assets will gradually depreciate in the long run. The decision maker is the manager, and his thinking angle is different from that of the technical staff. The benefits and costs are the issues that the decision maker is more concerned about.
2. Cost considerations. Costs include monetary assets, but also people and time. By choosing to form an IPv6 committee or working group and consulting with other business leaders, establish an IPv6 migration plan and integrate it with other businesses, such as PC replacement, application upgrade deployment or data center update. These are all conducive to the reduction of migration costs.
3. Reduce complexity. To ensure nothing is missed, a plan must be developed that will detail the timeline, groups of devices to be migrated, priorities, and more. To reduce complexity, you can do this by scheduling migrations by group, device, time, or whatever works best for you.
4. Active training. Through active training, the technical threshold for people to use IPv6 is lowered, not only for IPv6 operation and maintenance managers, but also for ordinary office workers. Although the use of IPv6 is similar to IPv4, there are still many differences. For example, when the browser enters the IPv6 address to access the URL, you need to add square brackets around the IPv6 address, and the IPv6 loopback address is ::1 instead of 127.0.0.1.  Although these places are very small, they really affect people's use of IPv6.

Haisheng Yu(Johnson)

[email-masked]

On 3/23/2022 13:57，Gert Doering<[email-masked]> wrote：

Hi,

Gert Doering
-- NetMaster

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 23 Mar 2022 08:37:22 +0000

Nick has given a URL with a detailed explanation. It has:
"ULA per RFC 6724 is less preferred (the Precedence value is lower) than all IPv4 (represented by ::ffff:0:0/96 in the table)."
I am puzzled why ::ffff:0:0/96 has been treated as IPv4? Strange interpretation.
The same section 2.1 has: "
Another effect of the default policy table is to prefer
   communication using IPv6 addresses to communication using IPv4
   addresses, if matching source addresses are available.
"
Nothing is stated about IPv6 type, "any" is assumed (including ULA).

Nick, are you sure that IPv4 prioritization over IPv6 ULS is really the case for real OSes?
If yes, IMHO: it is the bug in implementation (non-compliance to RFC 6724).

/Ed
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Tuesday, March 22, 2022 11:48 PM
To: [email-masked]; Ted Lemon <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] Thoughts about wider operational input

Nick,

Regards
    Brian Carpenter

On 23-Mar-22 09:35, Nick Buraglio wrote:
> simple examples of the behavior to the list. My experience has been, 
> and continues to be, that if I have dual stacked hosts with A and AAAA 
> records, and the IPv6 clients are using ULA that IPv6 is never used. 
> In an IPv6-only environment ULA has no higher priority protocol to 
> supersede the ULA. In the context of transitioning to an IPv6 world, 
> it is fairly unrealistic to assume any kind of greenfield, and 
> dual-stack
> work-life easier if I was. So, yes, I fully acknowledge that your use 
> case is absolutely the right one for ULA. For doing a transition in an 
> existing network (which circles back the the original topic of this 
> thread: getting enterprises to use IPv6 in a meaningful way), this is 
> a really
well put together descriptions of the every-day implications of trying to use ULA:
> <https://blogs.infoblox.com/ipv6-coe/ula-is-broken-in-dual-stack-netwo
> rks/>
> 
> nb
> 
> 
> 
> 
> 
any way of understanding why you believe this. In fact we're using ULAs in the Thread Border Router to enable IPv6 communication between different subnets, which literally could not be done with IPv4. So at least for this use case, ULAs work well. Would it work better to have a GUA? Comme ci comme ça. On the one hand, prefix delegation and real routing would make the solution more general. On the other, GUAs are great for reaching out to the internet, which we may or may not want light bulbs to be able to do.
>             should have two independent paths to the Internet to 
> assure
reliability.
>             That means two different ISPs (or less good, two 
> completely
independent
> <https://www.ietf.org/mailman/listinfo/v6ops>
> 
> <https://www.ietf.org/mailman/listinfo/v6ops>
>

---

From: Scott Morizot <[email-masked]>
Date: Wed, 23 Mar 2022 04:45:32 -0500

> If yes, IMHO: it is the bug in implementation (non-compliance to RFC 6724).
Here's the default prefix policy table in Windows. I believe that counts as
a real OS. And that is what RFC 6724 says to do. And altering it changes
things at the system level like the order of entries in the linked list
returned by GetAddrInfoW().

C:\bin>netsh interface ipv6 show prefixpolicies
Querying active state...

Precedence  Label  Prefix
----------  -----  --------------------------------
        50      0  ::1/128
        40      1  ::/0
        35      4  ::ffff:0:0/96
        30      2  2002::/16
         5      5  2001::/32
         3     13  fc00::/7
         1     11  fec0::/10
         1     12  3ffe::/16
         1      3  ::/96

---

From: Nick Buraglio <[email-masked]>
Date: Wed, 23 Mar 2022 08:52:03 -0500

The point I am trying to make is to address the initial question about
enterprise deployment of IPv6. The fact that we are talking about
manually changing the behavior of an off the shelf operating system,
and that the behavior may be inconsistent at best and incorrect at
worst across said systems /is/ the impediment. As Chongfeng states
further up the thread, there is a sizable gap between IETF and
enterprise deployment, where "enterprise" is defined as somewhere that
the network is a cost center that enables their business.
My counter-questions are these:
How can the IETF provide guidance that fills that gap?
Is it the right place to do so?

nb

---

From: Nick Buraglio <[email-masked]>
Date: Wed, 23 Mar 2022 08:53:14 -0500

My testing and experience has shown this, yes, and I know others have
had this experience as well.

nb

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Mar 2022 09:07:35 +1300

> I am puzzled why ::ffff:0:0/96 has been treated as IPv4? Strange interpretation.

Not at all strange. By definition (see RFC4291, section 2.5.5.2) that is the entire
IPv4 address space, respresented as an IPv6 prefix.

The problem is that RFC 6724 asserts that it sets IPv6 precedence above IPv4,
but in fact it sets ULA precedence below IPv4. That is a glaring error in
RFC 6724 - either text is wrong or the table is wrong. The behaviour that 
Nick
reports is conformance to the default table in RFC 6724, which is non-confromance
to the text.

Regards
    Brian Carpenter

>> any way of understanding why you believe this. In fact we're using ULAs in the Thread Border Router to enable IPv6 communication between different subnets, which literally could not be done with IPv4. So at least for 
this use case, ULAs work well. Would it work better to have a GUA? Comme ci comme ça. On the one hand, prefix delegation and real routing would make the solution more general. On the other, GUAs are great for reaching out to the internet, which we may or may not want light bulbs to be able to do.

---

From: Joe Maimon <[email-masked]>
Date: Wed, 23 Mar 2022 16:31:54 -0400

> IPv4 address space, respresented as an IPv6 prefix.
There is 2 thing at play. IPv6 packets with IPv4 embedded addresses as 
either or both source and destination.

And IPv4 packets with IPv4 addresses for both source and destination.

Perhaps they should be ranked individually.

Joe

---

From: Mark Andrews <[email-masked]>
Date: Thu, 24 Mar 2022 07:48:17 +1100

The table is designed to be patched for local topology. You add in the local ULA prefixes before IPv4.  The default will allow connection to succeed provided hosts and links are up and configured as expected on the first attempt.   If you push ULA above IPv4 and you have a non reachable ULA you are need fast failover to the next address. 

The OP complaint about the table indicates lack of understanding of what is intended. 

Note there are defined mechanisms for distributing a more site specific table. The OS and administrators should avail themselves of them.  A node doesn’t necessarily have the requisite knowledge to do this for itself (multiple ULA prefixes reachable). It can add directly connected prefixes. 
-- 
Mark Andrews

> On 24 Mar 2022, at 07:07, Brian E Carpenter <[email-masked]> wrote:
> 
> Eduard, you wrote:
> 
> RFC 6724 - either text is wrong or the table is wrong. The behaviour that Nick

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 23 Mar 2022 21:21:38 +0000

Hi Mark,
Happy Eyeballs would easily handle all situations when ULA is between GUA and IPv4 on priority.
Imagine that only ULA and IPv4 are available, but GUA is not. HYv2 should select 1 IPv6 and 1 IPv4 for initial competition.
If ULA has NPT then it would win (because of 50ms), if ULA is local-only then IPv4 would win.
Everything is fine because HYv2 should try both address spaces.

But you are right in general.
If no HYv2 on the host then the host would choose only ULA. If ULA is local-only then would be no internet connectivity.

IMHO: it means that some aspects of HYv2 should be incorporated into RFC 6724bis. To satisfy all scenarios.

By the way, it does not contradict with Brian said: RFC 6724 has no consistency between English text and policy table in section 2.1.
It is for sure Errata.

Eduard
-----Original Message-----
From: Mark Andrews [mailto:[email-masked]] 
Sent: Wednesday, March 23, 2022 11:48 PM
To: Brian E Carpenter <[email-masked]>
Cc: [email-masked]; Vasilenko Eduard <[email-masked]>; [email-masked]
Subject: Re: [v6ops] Thoughts about wider operational input

> The problem is that RFC 6724 asserts that it sets IPv6 precedence 
> above IPv4, but in fact it sets ULA precedence below IPv4. That is a 
> glaring error in RFC 6724 - either text is wrong or the table is 
> wrong. The behaviour that Nick reports is conformance to the default 
> table in RFC 6724, which is non-confromance to the text.
> 
> Regards
>   Brian Carpenter
> 
>>>> simple examples of the behavior to the list. My experience has 
>>>> been, and continues to be, that if I have dual stacked hosts with A 
>>>> and AAAA records, and the IPv6 clients are using ULA that IPv6 is never used.
>>>> supersede the ULA. In the context of transitioning to an IPv6 
>>>> world, it is fairly unrealistic to assume any kind of greenfield, 
>>>> and dual-stack
>>> is by and large the standard "permanently temporary" solution for 
>>> the vast majority of implementations. So in this context, which has 
>>> been 99% of what I have seen until I began working on the IPv6-only 
>>> implementation
>>>> I would be happy to be incorrect about this, honestly it would make 
>>>> my work-life easier if I was. So, yes, I fully acknowledge that 
>>>> your use case is absolutely the right one for ULA. For doing a 
>>>> transition in an existing network (which circles back the the 
>>>> original topic of this
>>>> thread: getting enterprises to use IPv6 in a meaningful way), this 
>>>> is a really
>>> well put together descriptions of the every-day implications of 
>>> trying
> to use ULA:
>>>> https://blogs.infoblox.com/ipv6-coe/ula-is-broken-in-dual-stack-net
>>>> wor
>>>> ks/
>>> any way of understanding why you believe this. In fact we're using 
>>> ULAs in the Thread Border Router to enable IPv6 communication 
>>> between different subnets, which literally could not be done with 
>>> IPv4. So at least for
>>>>              > My stance on this is that for "largely unmanaged 
>>>> SoHo
> networks" - which
>>>>              > could be called "small enterprise" - 
>>>> dual-enduser-ISP
> with dual-/48 or
>>>>             peace). Which is why I worked on RFC 8028. If that's 
>>>> not
> the
>>>>              > Half of them do not want Internet access anyway, 
>>>> just
> access to their
>>>>              > then out to the Internet as a new TCP session (= 
>>>> could
>>> be done with
>>>>              > DMZ islands of upstream-provider-allocated space 
>>>> just
> fine).
>>>>              >
>>>>              >

---

From: Nick Buraglio <[email-masked]>
Date: Wed, 23 Mar 2022 16:41:53 -0500

This is very interesting, and it definitely was something I was not aware
of. I am guessing this is also fairly unknown to others as well.
Is there any more documentation on the intention of this table as it
pertains to multiple platforms and embedded systems? I’d love to read
whatever is available, and I’ll do a bit more research myself to see what
is out there.

nb

On Wed, Mar 23, 2022 at 15:48 Mark Andrews <[email-masked]> wrote:

> The table is designed to be patched for local topology. You add in the
> local ULA prefixes before IPv4.  The default will allow connection to
> succeed provided hosts and links are up and configured as expected on the
> first attempt.   If you push ULA above IPv4 and you have a non reachable
> ULA you are need fast failover to the next address.
>
> Note there are defined mechanisms for distributing a more site specific
> table. The OS and administrators should avail themselves of them.  A node
> doesn’t necessarily have the requisite knowledge to do this for itself
> (multiple ULA prefixes reachable). It can add directly connected prefixes.
> --
> Mark Andrews
>
> >>> "ULA per RFC 6724 is less preferred (the Precedence value is lower)
> than all IPv4 (represented by ::ffff:0:0/96 in the table)."
> >>>> <
> https://blogs.infoblox.com/ipv6-coe/ula-is-broken-in-dual-stack-netwo
> >>>> rks/>
> >>>>
> >>>> nb
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> ULAs in the Thread Border Router to enable IPv6 communication between
> different subnets, which literally could not be done with IPv4. So at least
> for
> > this use case, ULAs work well. Would it work better to have a GUA? Comme
> ci comme ça. On the one hand, prefix delegation and real routing would make

---

From: Mark Andrews <[email-masked]>
Date: Thu, 24 Mar 2022 08:51:20 +1100

Happy Eyeballs works well enough for TCP.  For other transports not so much.

As for the text, yes it should have been updated when the table was updated.

> On 24 Mar 2022, at 08:21, Vasilenko Eduard <[email-masked]> wrote:
> 
> Hi Mark,

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 24 Mar 2022 11:22:42 +1100

RFC 6724, Default Address Selection for Internet Protocol Version 6 (IPv6)

   An implementation MAY automatically add additional site-specific rows
   to the default table based on its configured addresses, such as for
   Unique Local Addresses (ULAs) [RFC4193] and 6to4 [RFC3056] addresses,
   for instance (see Sections 10.6 and 10.7 for examples).  Any such
   rows automatically added by the implementation as a result of address
   acquisition MUST NOT override a row for the same prefix configured
   via other means.  That is, rows can be added but never updated
   automatically.  An implementation SHOULD provide a means (the
   Automatic Row Additions flag) for an administrator to disable
   automatic row additions.

RFC 7078 Distributing Address Selection Policy Using DHCPv6 instead of
using puppet.

> On 24 Mar 2022, at 08:41, Nick Buraglio <[email-masked]> wrote:
> 
> This is very interesting, and it definitely was something I was not aware of. I am guessing this is also fairly unknown to others as well. 
> Is there any more documentation on the intention of this table as it pertains to multiple platforms and embedded systems? I’d love to read whatever is available, and I’ll do a bit more research myself to see what is out there. 
> 
> nb
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Mar 2022 15:00:10 +1300

Yes, that's the theory. The trouble is that the default produces the problem that Nick describes, and configuring the table is far from straightforward, so ULAs don't work out of the box.

Regards
    Brian Carpenter

table. The OS and administrators should avail themselves of them.  A node 
doesn’t necessarily have the requisite knowledge to do this for itself (multiple ULA prefixes reachable). It can add directly connected prefixes.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Mar 2022 15:01:49 +1300

> RFC 7078 Distributing Address Selection Policy Using DHCPv6 instead of

i.e., not for Android...

    Brian

>> The table is designed to be patched for local topology. You add in the 
local ULA prefixes before IPv4.  The default will allow connection to succeed provided hosts and links are up and configured as expected on the first attempt.   If you push ULA above IPv4 and you have a non reachable ULA you are need fast failover to the next address.
>>>>>> thread: getting enterprises to use IPv6 in a meaningful way), this 
is
>>> this use case, ULAs work well. Would it work better to have a GUA? Comme ci comme ça. On the one hand, prefix delegation and real routing 
would make the solution more general. On the other, GUAs are great for reaching out to the internet, which we may or may not want light bulbs to be able to do.
>>>>>>               >> I agree with Jordi that multihoming is a genuine impediment. What isn't generally realised is that it's a problem of scale 
when considering at least 10,000,000 enterprises, much more than it's a problem of IPv6 itself.
could

---

From: Daniel Woititz <[email-masked]>
Date: Thu, 24 Mar 2022 14:07:29 +0800

Hi Nick,

Is it the right place to do so?
I think so. The technology needs to be useful. Even though the IETF is non-profit, the users should be thought of as customers. Learn customer needs and then work from there. maybe we should used the word "consumer" instead of "customer".

How can the IETF provide guidance that fills that gap?
This, and probably many other items, would go back to the answer above. Who and how are the major consumers of the product. How to best cater to them?

-- 

Thank you,

Danny Woititz
Founder and Primary Author of MasterIPv6.com <https://www.MasterIPv6.com>

---

From: Owen DeLong <[email-masked]>
Date: Wed, 23 Mar 2022 23:44:51 -0700

IIRC, ::ffff:a.b.c.d/96 is never supposed to be present in a packet on the wire.

I believe it is intended to allow software to be coded for IPv6 and have the operating system
do connections over IPv4 or IPv6 without the software having to have any special IPv4
related code.

Owen

> On Mar 23, 2022, at 13:31 , Joe Maimon <[email-masked]> wrote:
> 
> 
> 
> Brian E Carpenter wrote:
>> Eduard, you wrote:
>> 
> There is 2 thing at play. IPv6 packets with IPv4 embedded addresses as either or both source and destination.
>

---

From: Paolo Volpato <[email-masked]>
Date: Thu, 24 Mar 2022 09:32:47 +0000

I go back to the initial question posed by Fred and discussed by Michael here below (and echoed by others in the thread).

Personally, I agree with what Michael says and this is also one of the conclusions I would draw from the analysis done in draft-ietf-v6ops-ipv6-deployment. Enterprises, whatever we mean by that term and with the due exceptions, don't care about IPv6, unless it supports/enables their business goals.

But I believe that enterprises are represented in the IETF, either directly or indirectly. 
As discussed at the v6ops session on Monday, if the proposal is to listen to the people who have challenges or are even opposing to IPv6 then we can think of finding room for listening/interacting with enterprises on that. Without discussing here how and where, Fred's idea to have a meeting at the next RIPE could be a first step (and if accepted I would be happy to give support).

I am pretty sure that the contributions we may collect as a WG could be the subject of an operational draft.

BR
Paolo 

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Ackermann, Michael
Sent: Tuesday, March 22, 2022 2:13 PM
To: Fred Baker <[email-masked]>; IPv6 Ops WG <[email-masked]>
Subject: Re: [v6ops] Thoughts about wider operational input

Good question Fred. 

Thanks

Mike

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Fred Baker
Sent: Monday, March 21, 2022 4:33 PM
To: IPv6 Ops WG <[email-masked]>
Subject: [v6ops] Thoughts about wider operational input

[External email]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 24 Mar 2022 10:35:59 +0100

In principle, what Android doesn't implement is IA_NA, not DHCP Information
Request. So in principle, this could be a solution for Android at some
point.

On Thu, Mar 24, 2022 at 3:02 AM Brian E Carpenter <
[email-masked]> wrote:

> >> This is very interesting, and it definitely was something I was not
> aware of. I am guessing this is also fairly unknown to others as well.
> whatever is available, and I’ll do a bit more research myself
> to see what is out there.
> >>
> >> nb
> >>
> above IPv4,
> the vast majority of implementations. So in this context, which has been
> 99% of what I have seen until I began working on the IPv6-only
> implementation
> >>> mandated by the USG OMB-M-21-07 document, that was the de facto
> standard (and will continue to be for enterprise deployments, in my
> opinion).
> my
> >>>>>>      I'm sure you believe this assertion, Nick, but you haven't
> given
> >>>>>> us
> >>> this use case, ULAs work well. Would it work better to have a GUA?
> Comme ci comme ça. On the one hand, prefix delegation and real routing
> would make the solution more general. On the other, GUAs are great for
> reaching out to the internet, which we may or may not want light bulbs to
> be able to do.
> >>>>>>
> >>>>>>          ULA is an operational non-starter in the presence of any
> dual stacked hosts.  Per its design, it just won't ever use IPv6 in any
> >>>>>>              I see that the discussion has been going on while I
> was sleeping, but I want to clarify below...

---

From: Ted Lemon <[email-masked]>
Date: Thu, 24 Mar 2022 10:41:32 +0100

Of course, the situation is a bit more complicated than you've said,
because we do both source and destination address selection, and the
decision of whether to use IPv4 is actually impacted by both choices. I
think what we really want is that if the destination address is an IPv4
address, obviously we choose IPv4, but if we have both an IPv4 and IPv6
destination addresses, then we may be able to choose IPv6, but not
necessarily.

If all we have for IPv6 is a ULA, and the destination address is a GUA,
there's no guarantee that communication is possible in both directions
using the ULA, so we might have to prefer to use IPv4 in this case. If the
destination address is a ULA with the same global ID, then I think it's
safe to prefer the ULA source address. If it's a ULA with a different
global ID, I don't think this is a safe assumption; in this case it's
probably safer to use IPv4.

So I don't agree with you Brian that the table is wrong—I suspect it was
written this way because it was the only way to write the table that
ensured that the right thing would happen in this corner case. In order to
address this corner case while preferring a ULA over an IPv4 source
address, we would have to add additional rules that explicitly test for
this situation.

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 24 Mar 2022 09:50:16 +0000

Ø  we would have to add additional rules that explicitly test for this situation.
+1

From: Ted Lemon [mailto:[email-masked]]
Sent: Thursday, March 24, 2022 12:42 PM
To: Brian E Carpenter <[email-masked]>
Cc: [email-masked]; Vasilenko Eduard <[email-masked]>; [email-masked]
Subject: Re: [v6ops] Thoughts about wider operational input

Of course, the situation is a bit more complicated than you've said, because we do both source and destination address selection, and the decision of whether to use IPv4 is actually impacted by both choices. I think what we really want is that if the destination address is an IPv4 address, obviously we choose IPv4, but if we have both an IPv4 and IPv6 destination addresses, then we may be able to choose IPv6, but not necessarily.

If all we have for IPv6 is a ULA, and the destination address is a GUA, there's no guarantee that communication is possible in both directions using the ULA, so we might have to prefer to use IPv4 in this case. If the destination address is a ULA with the same global ID, then I think it's safe to prefer the ULA source address. If it's a ULA with a different global ID, I don't think this is a safe assumption; in this case it's probably safer to use IPv4.

So I don't agree with you Brian that the table is wrong—I suspect it was written this way because it was the only way to write the table that ensured that the right thing would happen in this corner case. In order to address this corner case while preferring a ULA over an IPv4 source address, we would have to add additional rules that explicitly test for this situation.

On Wed, Mar 23, 2022 at 9:07 PM Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:

Regards
    Brian Carpenter

On 24-Mar-22 02:53, Nick Buraglio wrote:
> <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> From: v6ops [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian E Carpenter
>> To: [email-masked]<mailto:[email-masked]>; Ted Lemon <[email-masked]<mailto:[email-masked]>>
>> Cc: [email-masked]<mailto:[email-masked]>
>>> On Tue, Mar 22, 2022 at 3:20 PM Ted Lemon <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>>
>>>
>>>      On Tue, Mar 22, 2022 at 9:13 PM Nick Buraglio <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>>
>>>          On Tue, Mar 22, 2022 at 2:55 PM Brian E Carpenter <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>>
>>>              Hi Gert,
>>>
>>>              [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>>>          [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

---

From: "Ackermann, Michael" <[email-masked]>
Date: Thu, 24 Mar 2022 10:06:07 +0000

Thank you Paolo
Good comments IMHO.  
This thread has gotten into topics  other than what I thought Fred was asking about, so I stopped responding.  
I agree with what you say and your ideas for moving this forward.     I think this could be important and  I would attempt to help in any way the WG or others  would like.   The warning I would provide is that it is VERY difficult to get enterprises to participate in initiatives such as this.   

Only one question I have is in regards to your statement about Enterprises are represented at IETF,  directly or indirectly.       My impression is that directly,  not much at all.   And if indirectly, means vendors,  I do not see that as an effective mechanism for articulating enterprise requirements,(challenges, use cases, preferences, etc).      
 But having made both of those statements I believe that this is largely our own fault for not participating.     We all have our reasons/excuses (lack of understanding, money, time, etc.),  but I believe all could be addressable, if IETF is serious.   I hope they are!

Thanks again

Mike

-----Original Message-----
From: Paolo Volpato <paolo.volpato=[email-masked]> 
Sent: Thursday, March 24, 2022 5:33 AM
To: Ackermann, Michael <[email-masked]>; Fred Baker <[email-masked]>; IPv6 Ops WG <[email-masked]>
Subject: RE: [v6ops] Thoughts about wider operational input

[External email]

BR
Paolo

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Ackermann, Michael
Sent: Tuesday, March 22, 2022 2:13 PM
To: Fred Baker <[email-masked]>; IPv6 Ops WG <[email-masked]>
Subject: Re: [v6ops] Thoughts about wider operational input

Good question Fred.

Thanks

Mike

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Fred Baker
Sent: Monday, March 21, 2022 4:33 PM
To: IPv6 Ops WG <[email-masked]>
Subject: [v6ops] Thoughts about wider operational input

[External email]

---

From: Philip Homburg <[email-masked]>
Date: Thu, 24 Mar 2022 12:29:37 +0100

>the end goal - see facebook etc)

Obviously, on an IPv6-only system, there is no IPv4, so the relative
priority of ULA compared to IPv4 does not matter.

I'm curious what IPv4aaS we want to deploy. I consider NAT64 a complete
disaster (even if the form of 464xlat). Given how the internet works, 
we will probably end up with NAT64 everywhere until the end of times.

>else in Big Enterprise land.

The problem with ULA is that we have lots of installations where hosts with
a ULA address don't have access to the IPv6 internet. Often, CPEs announce
a ULA when the CPE doesn't have an IPv6 uplink. 

In contrast, where RFC 1918 was meant for local IPv4 communication, it is 
now on a very large scale the primary method for a host to reach the IPv4
internet.

So to avoid the situation where we say that ULA is local and then use it
to connect to the IPv6 internet, we should just allocate a new space. And
explicitly give it the property to connect to the IPv6 internet through
through some sort of address translation.

There is also a nice tie-in with PI. Obviously, putting millions of PI
prefixes in BGP does not scale.

On the other hand, there is no such limit if the PI space is used behind NAT.

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Thu, 24 Mar 2022 13:24:21 +0100

Hi,

as someone who has transitioned from academia and ISP land towards cloud and enterprise territory, I begin to realise that being representation through the vendors is a very problematic assumption. As usually ISPs have huge equipment footprints compared to enterprises, at least budget wise, it is much easier for them getting their needs addrsses at the vendors and, thus, being represented by vendors if they choose not to be present on their own.

Most enterprise networks, are far less technology driven that ISPs and get far less management attention. 
For larger enterprises, a transition to IPv6 involves many internal teams to coordinate, it is more an organisational challenge than a technical challenge that is hard to drive without management attention. Pushing for IPv6 because of technological arguments won’t work – you need red flags it solves to get the necessary attention.
   
What can the IETF do to push IPv6 in the enterprise?
- Most effective would be to lobby to make IPv6 transition a hype topic. 
  ISP and vendor lobby and sales could help.
- Second, actively engaging consulting firms and education them could push that too.
  There are a bunch of very good IPv6 consultants there, but getting an IPv6 expert from
  one of the usual large consulting companies is difficult.
- Third, reaching out to PaaS communities like Kubernetes or Cloud Foundry could help to
  improve the IPv6 support there and make these platforms spread the word about IPv6.
- Last, take a look at the IaaS providers and try to engage them here.
  IPv6 support from AWS got usable in 2021.
  GCP is fine for PoCs, but functionality still very limited.
  Azure's IPv6 support is IPv4 with 128bit addresses.

AVE!
  Philipp 

> On 24. Mar 2022, at 11:06, Ackermann, Michael <MAckermann=[email-masked]> wrote:
> 
> Thank you Paolo
> Good comments IMHO. 

AVE!
   Philipp S. Tiesel

--  
Philipp S. Tiesel
https://philipp.tiesel.net/

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Mar 2022 09:04:10 +1300

(Trying, far too late, to change the Subject to be the actual subject...)

I wasn't paying enough attention when RFC6724 was done. I think it's even
more wrong each time I look at it. For example, it has the consequence that
if a pair of hosts have both RFC1918 and ULA addresses, the default for
communication between them is RFC1918. D'Oh. If two hosts have ULAs in the
same /64, they will nevertheless try IPv4 first. D'Oh. And the default table
in RFC6724 is sticky in practice, even if configurable in theory.

I think this needs serious work (in 6MAN most likely).

Regards
    Brian Carpenter

On 25-Mar-22 00:29, Philip Homburg wrote:
> .

---

From: Nick Buraglio <[email-masked]>
Date: Thu, 24 Mar 2022 16:20:58 -0500

I am happy to participate, and would like to help with this effort.

nb

---

From: Mark Andrews <[email-masked]>
Date: Fri, 25 Mar 2022 11:36:37 +1100

> On 25 Mar 2022, at 07:04, Brian E Carpenter <[email-masked]> wrote:
> 

Swap MAY to SHOULD on adding ULA prefixes (10.6.Configuring ULA Preference)
would get the desired behaviour.

The following would need to reworded to seperate out the advice for ULA
from 6to4.

   An implementation MAY automatically add additional site-specific rows
   to the default table based on its configured addresses, such as for
   Unique Local Addresses (ULAs) [RFC4193] and 6to4 [RFC3056] addresses,
   for instance (see Sections 10.6 and 10.7 for examples).

---

From: "Ackermann, Michael" <[email-masked]>
Date: Fri, 25 Mar 2022 10:05:32 +0000

Thanks Brian
Agree on the subject change and agree on  having this looked at in 6MAN.  

I believe that if/when enterprises finally move to IPv6, there will be several ULA use case candidates.   But only if they work right.   Several of these issues you outlined below would seem to force a lot of traffic to stay on ipv4.   
Thanks for looking into this!

Mike

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Brian E Carpenter
Sent: Thursday, March 24, 2022 4:04 PM
To: Philip Homburg <[email-masked]>; [email-masked]
Subject: [v6ops] ULA precedence [Thoughts about wider operational input]

[External email]

I wasn't paying enough attention when RFC6724 was done. I think it's even more wrong each time I look at it. For example, it has the consequence that if a pair of hosts have both RFC1918 and ULA addresses, the default for communication between them is RFC1918. D'Oh. If two hosts have ULAs in the same /64, they will nevertheless try IPv4 first. D'Oh. And the default table in RFC6724 is sticky in practice, even if configurable in theory.

Regards
    Brian Carpenter

On 25-Mar-22 00:29, Philip Homburg wrote:
>> of IPv4, plus the added complications of dual-stack.  Services need 
>> to be dual-stack, but for all the rest, single-stack IPv6 needs to be 
> I'm curious what IPv4aaS we want to deploy. I consider NAT64 a 
> complete disaster (even if the form of 464xlat). Given how the 
> internet works, we will probably end up with NAT64 everywhere until the end of times.
>
>> way forward, IETF can update RFCs, and vendors will eventually update 
>> their base OS.  It might take 5 years, but so will everything else in 
>> Big Enterprise land.
>
> The problem with ULA is that we have lots of installations where hosts 
> with a ULA address don't have access to the IPv6 internet. Often, CPEs 
> announce a ULA when the CPE doesn't have an IPv6 uplink.
>
> In contrast, where RFC 1918 was meant for local IPv4 communication, it 
> is now on a very large scale the primary method for a host to reach 
> the IPv4 internet.
>
> So to avoid the situation where we say that ULA is local and then use 
> it to connect to the IPv6 internet, we should just allocate a new 
> space. And explicitly give it the property to connect to the IPv6 
> internet through through some sort of address translation.
>

---

From: Paolo Volpato <[email-masked]>
Date: Fri, 25 Mar 2022 10:20:59 +0000

Hi,
Following on what you and Michael provided, I wonder if involving the cloud providers more in this domain may prove useful to increase the representativeness of enterprises in the IETF. 
In any case, if there is enough interest from the community to deal with the aspects related to IPv6 in the enterprise I would also happy to contribute.
BR
Paolo

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Philipp S. Tiesel
Sent: Thursday, March 24, 2022 1:24 PM
To: IPv6 Ops WG <[email-masked]>
Subject: Re: [v6ops] Thoughts about wider operational input

Hi,

   

AVE!
  Philipp 

AVE!
   Philipp S. Tiesel

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 25 Mar 2022 14:40:17 +0000

Hi Mark,
It would not work.
Who would be doing this "SHOULD"?
Home subscriber? Or SMB entrepreneur?
I could imagine how "dog hairdresser" would be changing policy table in OpenWRT Linux.
IMHO: It should be more automatic.
Eduard
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Mark Andrews
Sent: Friday, March 25, 2022 3:37 AM
To: Brian E Carpenter <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] ULA precedence [Thoughts about wider operational input]

> I wasn't paying enough attention when RFC6724 was done. I think it's 
> even more wrong each time I look at it. For example, it has the 
> consequence that if a pair of hosts have both RFC1918 and ULA 
> addresses, the default for communication between them is RFC1918. 
> D'Oh. If two hosts have ULAs in the same /64, they will nevertheless 
> try IPv4 first. D'Oh. And the default table in RFC6724 is sticky in practice, even if configurable in theory.

Swap MAY to SHOULD on adding ULA prefixes (10.6.Configuring ULA Preference) would get the desired behaviour.

The following would need to reworded to seperate out the advice for ULA from 6to4.

>>> (Dual-stack cannot be the answer anyway - it will have all the 
>>> issues of IPv4, plus the added complications of dual-stack.  
>>> Services need to be dual-stack, but for all the rest, single-stack 
>>> IPv6 needs to be the end goal - see facebook etc)
>> The problem with ULA is that we have lots of installations where 
>> hosts with a ULA address don't have access to the IPv6 internet. 
>> Often, CPEs announce a ULA when the CPE doesn't have an IPv6 uplink.
>> In contrast, where RFC 1918 was meant for local IPv4 communication, 
>> it is now on a very large scale the primary method for a host to 
>> reach the IPv4 internet.
>> There is also a nice tie-in with PI. Obviously, putting millions of 
>> PI prefixes in BGP does not scale.

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 25 Mar 2022 14:42:00 +0000

+1

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Nick Buraglio
Sent: Friday, March 25, 2022 12:21 AM
To: Brian E Carpenter <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] ULA precedence [Thoughts about wider operational input]

nb

On Thu, Mar 24, 2022 at 3:04 PM Brian E Carpenter <[email-masked]> wrote:
> >> update their base OS.  It might take 5 years, but so will 
> >> everything else in Big Enterprise land.
> >
> > So to avoid the situation where we say that ULA is local and then 
> > use it to connect to the IPv6 internet, we should just allocate a 
> > new space. And explicitly give it the property to connect to the 
> > IPv6 internet through through some sort of address translation.
> >

---

From: Bob Hinden <[email-masked]>
Date: Fri, 25 Mar 2022 08:08:36 -0700

Brian,

> On Mar 24, 2022, at 1:04 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Without any hats on, I agree.   Suggest you start a thread on the IPv6 list with some proposed changes and/or write a draft.

Bob

---

From: Mark Smith <[email-masked]>
Date: Sat, 26 Mar 2022 11:31:54 +1100

On Fri, 25 Mar 2022, 07:04 Brian E Carpenter, <[email-masked]>
wrote:

> I wasn't paying enough attention when RFC6724 was done.

Neither was I.

I assumed it was swapping site-locals for ULAs, because the issue with
site-locals was their lack of uniqueness. Otherwise, preference over GUAs
etc. was all fine.

RFC6724 now preferrs GUAs over ULAs, which defeats the use of ULAs to
provide internal connectivity while performing a GUA renumber, which is one
of the ULA use cases mentioned in RFC4193, and I think one of the main
reasons to have a parallel internal/local address space.

The justification for that change in RFC6724 is that GUAs seems to be that
they may be more reliably reached than ULAs (section 10.6). I don't agree,
I think in general local addressing will inherently be more reliable than
global addressing.

However, a GUA address could be more reliably reached than the equivalent
ULA for the destination at the time any particular connection is attempted.

So I've been thinking we should:

- change the preference of ULAs to over GUAs (and IPv4), to facilitate GUA
renumbering per RFC4193.

- recommend the use of Happy Eyeballs v2 at the time of the connection
attempt to address the issue of a GUA DA being available when the
equivalent ULA DA might not be, addressing the situation that caused ULAs
to be put below GAUs.

- suggest and possibly recommend multi-path transport protocols like MPTCP
that would connect to both (all) available GUAs and ULAs, providing
robustness against either GUA or ULA addresses going away during the
connection.

Regards,
Mark.

I think it's even
> with

---

From: "Ackermann, Michael" <[email-masked]>
Date: Sat, 26 Mar 2022 00:55:28 +0000

Paolo
Thanks for following up.  
I was intrigued by when you said "involving cloud providers may increase the representation of enterprises at IETF"    I am not sure what that means, or how this could effect enterprise attendance/representation  at IETF,  but increasing enterprise attendance/represetation at IETF is a very important topic to me (that I have had little success with to date), so you definitely have my attention.   Can you elaborate on how this might work?  

As you probably know,  enterprises are doing a LOT with Clouds right now and more planned for the future.     As we move apps to the cloud,  we are finding limitations in addressing and routing.  Sometimes resulting in lack of connectivity, degraded performance, unexpected costs and other issues.  NAT's seem to be particularly problematic in certain areas with clouds.    IPv6 seems to be a good potential solution.   Currently, we are trying to find out the specifics of these issues,  with the various cloud vendors,  regarding addressing formats, limits, routing, costs and other involved operational details.   This should provide a more efficient, effective and capable ecosystem, for both the customers and the cloud vendors.   These issues are of particular significance when apps span VPCs, geographic boundaries, or even cloud vendors. 
IMHO the cloud vendors are starting to see that IPv6 would be good for them as well.  (more addresses, less NATs & other performance issues, and not to even mention the cost of acquiring more IPv4 space if we don't jointly pursue v6. 

So if you,  or anyone else at IETF,  can assist with either of the two subjects above,  or anything else in this space,  we (enterprises) need LOTSA help and like I said,  you very much have my attention. 

Thanks 

Mike 

-----Original Message-----
From: Paolo Volpato <paolo.volpato=[email-masked]> 
Sent: Friday, March 25, 2022 6:21 AM
To: Philipp S. Tiesel <[email-masked]>; IPv6 Ops WG <[email-masked]>
Cc: Ackermann, Michael <[email-masked]>
Subject: RE: [v6ops] Thoughts about wider operational input

[External email]

Hi,

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Philipp S. Tiesel
Sent: Thursday, March 24, 2022 1:24 PM
To: IPv6 Ops WG <[email-masked]>
Subject: Re: [v6ops] Thoughts about wider operational input

Hi,

AVE!
  Philipp

AVE!
   Philipp S. Tiesel

---

From: Vasilenko Eduard <[email-masked]>
Date: Sat, 26 Mar 2022 11:56:16 +0000

Hi all,

Mark’s proposal fixes ULA+NPT case.
I would like to talk about the case of choosing from 2 sources GUAs. (ULA may not exist at all). It is the strategic direction, right?

For every problem, RFC 6724 should be analyzed twice:

1.       If the destination address is chosen 1st (more typical situation)

2.       If the source address is chosen 1st (I hope we do not have the intention to deprecate such possibility – it is needed for prefixes unequally accepted by 3rd parties)

For 1: (more typical situation)
Section6: DNS would probably return GUA (not ULA). Hence GUA would be chosen as the destination.
Then
Section5: rule8 (longest match) would probably choose GUA as the source
Conclusion: fine, even after Mark's proposal.

For 2: (advanced functionality for the future)
Section 5: no one rule is applicable. Why not choose ULA, especially if it is prioritized by precedence (that is, in reality, applicable only for destination address selection)
ULA choice as the source would probably break connectivity because DNS would probably return GUA, but it would be checked later.

I mean: the second approach that was promised
“
Another implementation strategy is to call down to the network layer
   to retrieve source address information and then sort the list of
   addresses directly in the context of getaddrinfo()
”
Is not really implemented in RFC 6724.
It is not possible to choose a source (from a few GUAs) that would not be filtered on the Internet.

Is it possible to fix this problem too? Or is it a too big change?
If we would not fix this problem then ULA+NPT would become a must.
More on the problem in section 5.1 https://datatracker.ietf.org/doc/html/draft-vv-6man-nd-prefix-robustness-02#page-13
But this draft fixes only the ND part of the problem.
“Default address selection” for many unequal GUAs is not touched yet.
And of course, home networking (HNCP or DHCP-PD) is needed to distribute prefixed inside site routed network.
The problem of proper choice for source GUA, in reality, is distributed in 3 places that must be fixed.

PS: this thread is more applicable to 6man – on copy.

Eduard
From: v6ops [mailto:[email-masked]] On Behalf Of Mark Smith
Sent: Saturday, March 26, 2022 3:32 AM
To: Brian E Carpenter <[email-masked]>
Cc: v6ops list <[email-masked]>
Subject: Re: [v6ops] ULA precedence [Thoughts about wider operational input]

On Fri, 25 Mar 2022, 07:04 Brian E Carpenter, <[email-masked]<mailto:[email-masked]>> wrote:
(Trying, far too late, to change the Subject to be the actual subject...)

Neither was I.

I assumed it was swapping site-locals for ULAs, because the issue with site-locals was their lack of uniqueness. Otherwise, preference over GUAs etc. was all fine.

RFC6724 now preferrs GUAs over ULAs, which defeats the use of ULAs to provide internal connectivity while performing a GUA renumber, which is one of the ULA use cases mentioned in RFC4193, and I think one of the main reasons to have a parallel internal/local address space.

The justification for that change in RFC6724 is that GUAs seems to be that they may be more reliably reached than ULAs (section 10.6). I don't agree, I think in general local addressing will inherently be more reliable than global addressing.

However, a GUA address could be more reliably reached than the equivalent ULA for the destination at the time any particular connection is attempted.

- change the preference of ULAs to over GUAs (and IPv4), to facilitate GUA renumbering per RFC4193.

- recommend the use of Happy Eyeballs v2 at the time of the connection attempt to address the issue of a GUA DA being available when the equivalent ULA DA might not be, addressing the situation that caused ULAs to be put below GAUs.

- suggest and possibly recommend multi-path transport protocols like MPTCP that would connect to both (all) available GUAs and ULAs, providing robustness against either GUA or ULA addresses going away during the connection.

Regards,
Mark.

I think it's even

Regards
    Brian Carpenter

---

From: Nick Buraglio <[email-masked]>
Date: Mon, 28 Mar 2022 11:33:59 -0500

> I was intrigued by when you said "involving cloud providers may increase the representation of enterprises at IETF"    I am not sure what that means, or how this could effect enterprise attendance/…

Anecdotally, from my experience working through IPv6-only requirements
I am seeing significant concern and questions about cloud support for
IPv6. As noted, non-ISPs have been (and are accelerating) adoption of
cloud services. As Michael has alluded to below, the complexity of
adding multiple layers of NAT is potentially problematic as compared
to end to end IPv6. The cloud providers have (seemingly begrudgingly
in many cases) started offering both dual stack and in some cases
IPv6-only services. With my work hat on, we have been attempting to
encourage IPv6 adoption within the major cloud providers in order to
accomodate our required move to IPv6-only, but it is definitely slow
going and is a significant amount of effort. This is only half of the
conversation, though, as enterprises are very often driven by support,
so if the IPv6 pieces and parts are considered "new" or "beta" or
whatever, then they are perceived as a risk. In many cases cloud IPv6
support is not as well supported or documented within the cloud
providers, so we have that to consider. In addition, finding the
"right folks" to engage can be a challenge.

> IMHO the cloud vendors are starting to see that IPv6 would be good for them as well.  (more addresses, less NATs & other performance issues, and not to even mention the cost of acquiring more IPv4…

This needs to be reinforced at every opportunity. RFPs, purchase order
requirements, evaluation criteria. Money talks.

> So if you,  or anyone else at IETF,  can assist with either of the two subjects above,  or anything else in this space,  we (enterprises) need LOTSA help and like I said,  you very much have my att…

It's not the most efficient, but what I have personally done is
basically a grassroots campaign - if I engage with the right people, I
refer them here. Part of what they should be interested in is scoping
and helping shephard the direction of what will likely be their future
path. I have certainly encouraged people to participate - or at least
pay attention - here and on 6man. It's a bit of a slog, but if it can
push things forward even an inch, I'll keep doing it.

---

From: Paolo Volpato <[email-masked]>
Date: Tue, 29 Mar 2022 14:51:52 +0000

The cloudification process puts anyway the cloud providers in a position that allows them to influence the choices of an enterprise.
I know I am probably simplifying the problem but in many cases it's likely that enterprises base their decision whether to use a cloudified service just considering the economic side without looking that much at its technical aspects. 
Cloud providers have the scale to take in consideration also the technical aspect in their equation when defining a service.
Most of them have adopted (or are adopting) IPv6 to solve the addressing issues in their DCs and some have started to offer IPv6-based services. I think they have the experience to deal with IPv6 and discuss its benefits.
I agree that, being based on a bottom-up approach, it is a lengthy process but with their involvement in explaining the advantages of IPv6 would be useful to change the enterprises' attitude.
As Nick suggested, I also see a role for them to contribute in defining an evolution path to IPv6. I see this something that can be addressed in the IETF. 
Hopefully this would bring to increased attention by them to the operational/support aspects mentioned below (which are a critical part of the problem).

BR
Paolo

-----Original Message-----
From: Nick Buraglio <[email-masked]> 
Sent: Monday, March 28, 2022 6:34 PM
To: Ackermann, Michael <[email-masked]>
Cc: Paolo Volpato <[email-masked]>; Philipp S. Tiesel <[email-masked]>; IPv6 Ops WG <[email-masked]>
Subject: Re: [v6ops] Thoughts about wider operational input

> I was intrigued by when you said "involving cloud providers may increase the representation of enterprises at IETF"    I am not sure what that means, or how this could effect enterprise attendance/…

Anecdotally, from my experience working through IPv6-only requirements I am seeing significant concern and questions about cloud support for IPv6. As noted, non-ISPs have been (and are accelerating) adoption of cloud services. As Michael has alluded to below, the complexity of adding multiple layers of NAT is potentially problematic as compared to end to end IPv6. The cloud providers have (seemingly begrudgingly in many cases) started offering both dual stack and in some cases IPv6-only services. With my work hat on, we have been attempting to encourage IPv6 adoption within the major cloud providers in order to accomodate our required move to IPv6-only, but it is definitely slow going and is a significant amount of effort. This is only half of the conversation, though, as enterprises are very often driven by support, so if the IPv6 pieces and parts are considered "new" or "beta" or whatever, then they are perceived as a risk. In many cases cloud IPv6 support is not as well supported or documented within the cloud providers, so we have that to consider. In addition, finding the "right folks" to engage can be a challenge.

> IMHO the cloud vendors are starting to see that IPv6 would be good for them as well.  (more addresses, less NATs & other performance issues, and not to even mention the cost of acquiring more IPv4…

This needs to be reinforced at every opportunity. RFPs, purchase order requirements, evaluation criteria. Money talks.

> So if you,  or anyone else at IETF,  can assist with either of the two subjects above,  or anything else in this space,  we (enterprises) need LOTSA help and like I said,  you very much have my att…

It's not the most efficient, but what I have personally done is basically a grassroots campaign - if I engage with the right people, I refer them here. Part of what they should be interested in is scoping and helping shephard the direction of what will likely be their future path. I have certainly encouraged people to participate - or at least pay attention - here and on 6man. It's a bit of a slog, but if it can push things forward even an inch, I'll keep doing it.

> > To: Ackermann, Michael <[email-masked]>; Fred Baker 
> > <[email-masked]>; IPv6 Ops WG <[email-masked]>
> > Another area that COULD be compelling is to highlight what issues 
> > may be faced if an Org stays on IPv4 only, for either the short or 
> > long term
> >

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 29 Mar 2022 15:03:32 +0000

A few years ago there was a Hype "Hybrid Cloud" (that accelerated Microsoft so much as the most successful on this topic),
Where Enterprise is totally dependent on the technology of the particular cloud provider.
Current heavy push in the US on all Cloud providers to become IPv6-only
Would almost automatically change the IP type of hybrid-dependent Enterprises.
Good sign at the end of the tunnel. I hope it is not the train.
Eduard
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Paolo Volpato
Sent: Tuesday, March 29, 2022 5:52 PM
To: [email-masked]; Ackermann, Michael <[email-masked]>
Cc: Philipp S. Tiesel <[email-masked]>; IPv6 Ops WG <[email-masked]>
Subject: Re: [v6ops] Thoughts about wider operational input

BR
Paolo

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 29 Mar 2022 15:30:38 +0000

Thanks Paulo
You make a lot of good points and ones that resonate with my experiences.  

Enterprises are becoming increasingly dependent upon the Clouds and as such,  like you say,  they end up influencing (and in some cases limiting),  our choices.    
I don't think you are simplifying.   We do make decision that are largely financial and consider related technical/operation aspects,  either too late or not at all.   And are living with issues as a result.    Nonetheless I expect the cloud exodus to continue for some time, so until then, it behooves us to work with Clouds,  to make their environments as efficient and effective as possible,  as that is directly conducive to our success as enterprises.  
Regards to IPv6, I think the clouds I have talked to are ahead of enterprises, (don't know much about Azure though),   but not as much as we would expect or that they should be.     It would be great to have IETF educate the Clouds and then have the Clouds help educate Enterprises, and thus promote IPv6 deployment there.        I may be dreaming here,  but those are my thoughts,  which seem to be pretty consistent with yours.

Thanks again

Mike

-----Original Message-----
From: Paolo Volpato <[email-masked]> 
Sent: Tuesday, March 29, 2022 10:52 AM
To: [email-masked]; Ackermann, Michael <[email-masked]>
Cc: Philipp S. Tiesel <[email-masked]>; IPv6 Ops WG <[email-masked]>
Subject: RE: [v6ops] Thoughts about wider operational input

[External email]

BR
Paolo

-----Original Message-----
From: Nick Buraglio <[email-masked]>
Sent: Monday, March 28, 2022 6:34 PM
To: Ackermann, Michael <[email-masked]>
Cc: Paolo Volpato <[email-masked]>; Philipp S. Tiesel <[email-masked]>; IPv6 Ops WG <[email-masked]>
Subject: Re: [v6ops] Thoughts about wider operational input

> For larger enterprises, a transition to IPv6 involves many internal teams to coordinate, it is more an organisational challenge than a technical challenge that is hard to drive without management attention. Pushing for IPv6 because of technological arguments won't work - you need red flags it solves to get the necessary attention.
>
> > None of these address what seems to me to be a core problem: ISPs are deploying, but enterprise isn't. How do we get enterprise on board?
> >

---

From: Nick Buraglio <[email-masked]>
Date: Tue, 29 Mar 2022 11:54:43 -0500

Slight correction - in the US the push has been (at least from where I
am sitting in the process) for cloud providers to simply /enable/
IPv6. For the majority of cases a dual stack cloud environment is
completely acceptable since memo M-21-07 states that IPv6-only is
required of government owned assets, which the cloud providers are
not. some have gone above and started offering IPv6-only, but as long
as the government assets are v6-only, the dual stacked nature of cloud
services are largely moot as the traffic should either take v6 or,
worst case a NAT64 path.
My real point is that we probably shouldn't rely on the IPv6-only
nature of M-21-07 to influence much more than dual stack (which is
still a huge win in my book because some v6 is better than no v6).

nb

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 29 Mar 2022 17:34:28 +0000

Agreed

We are working with Nick and others at HHS.    They are a long way from IPv6 deployment,  much less IPv6 only.   And they are the lead in several USG initiatives.   So I am not holding my breath,  but this is the most serious and real effort at IPv6 and one that Enterprises will (I am hoping), be forced to follow and model.  

-----Original Message-----
From: Nick Buraglio <[email-masked]> 
Sent: Tuesday, March 29, 2022 12:55 PM
To: Vasilenko Eduard <[email-masked]>
Cc: Paolo Volpato <paolo.volpato=[email-masked]>; Ackermann, Michael <[email-masked]>; Philipp S. Tiesel <[email-masked]>; IPv6 Ops WG <[email-masked]>
Subject: Re: [v6ops] Thoughts about wider operational input

[External email]

Slight correction - in the US the push has been (at least from where I am sitting in the process) for cloud providers to simply /enable/ IPv6. For the majority of cases a dual stack cloud environment is completely acceptable since memo M-21-07 states that IPv6-only is required of government owned assets, which the cloud providers are not. some have gone above and started offering IPv6-only, but as long as the government assets are v6-only, the dual stacked nature of cloud services are largely moot as the traffic should either take v6 or, worst case a NAT64 path.
My real point is that we probably shouldn't rely on the IPv6-only nature of M-21-07 to influence much more than dual stack (which is still a huge win in my book because some v6 is better than no v6).

nb

On Tue, Mar 29, 2022 at 10:03 AM Vasilenko Eduard <[email-masked]> wrote:
>
> A few years ago there was a Hype "Hybrid Cloud" (that accelerated 
> Microsoft so much as the most successful on this topic), Where Enterprise is totally dependent on the technology of the particular cloud provider.
> Current heavy push in the US on all Cloud providers to become 
> IPv6-only Would almost automatically change the IP type of hybrid-dependent Enterprises.
> Cc: Paolo Volpato <[email-masked]>; Philipp S. Tiesel 
> <[email-masked]>; IPv6 Ops WG <[email-masked]>

---

From: Fred Baker <[email-masked]>
Date: Tue, 29 Mar 2022 12:37:25 -0700

> On Mar 29, 2022, at 7:51 AM, Paolo Volpato <paolo.volpato=[email-masked]> wrote:
> 

I don't disagree with you in the least. That brings me back to my original question, however:

Can we get someone-that's-not-a-vendor-academic-or-ISP (using the word "enterprise" seems to be confusing) give a talk in v6ops in Philadelphia about what their proposed evolutionary target for IPv6 might be?

---

From: Nalini J Elkins <[email-masked]>
Date: Tue, 29 Mar 2022 19:57:59 +0000 (UTC)

Sorry for the top post.  I am on my phone.
I am talking to such an organization about presenting in Philadelphia on their IPv6 planning.  They are trying to get authorization from their legal and other departments.  My fingers are crossed.
It is a process.
Nalini 

Sent from Smallbiz Yahoo Mail for iPhone

---

From: Xipengxiao <[email-masked]>
Date: Tue, 29 Mar 2022 22:38:23 +0000

Hi Fred,

I volunteer to work with Michael, Nick, Nalini, Paolo, Eduard and Philipp et al to find a few candidates, so that you and Ron can select 1-2 to talk in v6ops in Philadelphia IETF. I suggest we select those who are hands-on and can talk about the challenges and lessons in depth.

XiPeng

---

From: "E. Marie Brierley" <[email-masked]>
Date: Tue, 29 Mar 2022 23:15:17 +0000

Great to see so much enthusiasm for enterprise!

Some of you know I had the honor (and horror) of leading the v6 transition of cisco.com. This effort was enormous and required the heavy involvement of both business applications and infrastructure teams (33 top level teams, 69 director sign-offs and 800+ applications). We proved IPv6 is capable of supporting business at Cisco scale.

https://www.cisco.com/c/dam/en_us/about/ciscoitatwork/borderless_networks/docs/M-EN-02242014-IPv6-Web-Presence.pdf
Cisco IT Expands IPv6 Web Presence<https://www.cisco.com/c/dam/en_us/about/ciscoitatwork/borderless_networks/docs/M-EN-02242014-IPv6-Web-Presence.pdf>
“IPv6 isn’t a business capability change. It’s a technology change. From a business stakeholder’s perspective, IPv6 should roll out without any business or customer impact,” says Kaali Dass, IT architect, Connected IT Services at Cisco.
www.cisco.com

My approach has been to pivot from addressing the issue with solely IT as I believe the business case takes precedence in non-internet widget industries, eg. healthcare, manufacturing, retail, finance. IT in these industries are buried in priorities with insufficient budgets. If the CEOs, CMO's, CRO's, etc. don't prioritize and budget the effort, IT will be reluctant to move forward. Every day with no progress means the legacy black hole gets bigger and bigger, creating more v6 inertia. I have so much to say on the subject, but I'll stay with brevity on this thread.

I'd be happy to add my business experience and messaging to the group effort.

E. Marie

________________________________
From: v6ops <[email-masked]> on behalf of Xipengxiao <xipengxiao=[email-masked]>
Sent: Tuesday, March 29, 2022 3:38 PM
To: Fred Baker <[email-masked]>; Paolo Volpato <paolo.volpato=[email-masked]>; [email-masked] <[email-masked]>
Cc: Philipp S. Tiesel <[email-masked]>; IPv6 Ops WG <[email-masked]>
Subject: Re: [v6ops] Thoughts about wider operational input

Hi Fred,

XiPeng

---

From: "Ackermann, Michael" <[email-masked]>
Date: Wed, 30 Mar 2022 02:00:04 +0000

Thanks XiPeng
And a +1  here.  

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Xipengxiao
Sent: Tuesday, March 29, 2022 6:38 PM
To: Fred Baker <[email-masked]>; Paolo Volpato <paolo.volpato=[email-masked]>; [email-masked]
Cc: Philipp S. Tiesel <[email-masked]>; IPv6 Ops WG <[email-masked]>
Subject: Re: [v6ops] Thoughts about wider operational input

[External email]

Hi Fred,

XiPeng

---

From: "Ackermann, Michael" <[email-masked]>
Date: Wed, 30 Mar 2022 02:11:10 +0000

I believe that EM is correct.
Most of the lack of ipv6 activity at enterprises is due to leadership showing no interest.  This is due to the perceived lack of a business case,  which keeps ipv6 out of the budget, and thus it is not on any planning radar,  much less in active project plans.

I still think we (enterprises), are lacking in ipv6 knowledge/expertise, and this needs to be addressed as well (and this is occurring).     But any assimilated knowledge will go to waste,  if there is no approved activity from above.

Thanks

Mike

From: v6ops <[email-masked]> On Behalf Of E. Marie Brierley
Sent: Tuesday, March 29, 2022 7:15 PM
To: Xipengxiao <xipengxiao=[email-masked]>; Fred Baker <[email-masked]>; Paolo Volpato <paolo.volpato=[email-masked]>; [email-masked]
Cc: Philipp S. Tiesel <[email-masked]>; IPv6 Ops WG <[email-masked]>
Subject: Re: [v6ops] Thoughts about wider operational input

[External email]

https://www.cisco.com/c/dam/en_us/about/ciscoitatwork/borderless_networks/docs/M-EN-02242014-IPv6-Web-Presence.pdf
Cisco IT Expands IPv6 Web Presence<https://www.cisco.com/c/dam/en_us/about/ciscoitatwork/borderless_networks/docs/M-EN-02242014-IPv6-Web-Presence.pdf>
"IPv6 isn't a business capability change. It's a technology change. From a business stakeholder's perspective, IPv6 should roll out without any business or customer impact," says Kaali Dass, IT architect, Connected IT Services at Cisco.
www.cisco.com<http://www.cisco.com>

E. Marie

________________________________
From: v6ops <[email-masked]<mailto:[email-masked]>> on behalf of Xipengxiao <xipengxiao=[email-masked]<mailto:xipengxiao=[email-masked]>>
Sent: Tuesday, March 29, 2022 3:38 PM
To: Fred Baker <[email-masked]<mailto:[email-masked]>>; Paolo Volpato <paolo.volpato=[email-masked]<mailto:paolo.volpato=[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: Philipp S. Tiesel <[email-masked]<mailto:[email-masked]>>; IPv6 Ops WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] Thoughts about wider operational input

Hi Fred,

XiPeng

-----Original Message-----
From: v6ops <[email-masked]<mailto:[email-masked]>> On Behalf Of Fred Baker
Sent: Tuesday, March 29, 2022 9:37 PM
To: Paolo Volpato <paolo.volpato=[email-masked]<mailto:paolo.volpato=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Philipp S. Tiesel <[email-masked]<mailto:[email-masked]>>; IPv6 Ops WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] Thoughts about wider operational input

> On Mar 29, 2022, at 7:51 AM, Paolo Volpato <paolo.volpato=[email-masked]<mailto:paolo.volpato=[email-masked]>> wrote:
>

---

From: Mark Smith <[email-masked]>
Date: Wed, 30 Mar 2022 14:22:15 +1100

> apps. We must aim for something better.

This.

IPv6+NAT creates a lot of the issues that IPv4+NAT does, so why bother
deploying IPv6 when you've already got the equivalent via IPv4 today?

People need to understand why enterprises go to the expense of deploying
technologies.

Technology is a means to an end, not the end itself. Technology in business
either saves money or makes money for the business.

Enterprises in the 1990s didn't really deploy IPv4, they deployed global
email and WWW access. Deploying IPv4 was the means to reaching those ends,
because IPv4 underpinned them.

So the questions to think about in the context of businesses and
enterprises and IPv6 are:

- What business problem does or can IPv6 solve better than existing IPv4?

- IPv6 is the technology means to an end, so what is or are the ends that
are of value to a business, where IPv6 is the better underpinning
technology than IPv4 to reach those ends?

- How can deploying IPv6 save or make money for a business?

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Mar 2022 17:06:08 +1300

> - What business problem does or can IPv6 solve better than existing IPv4?

That suggests to me that an even earlier question is:

  - What business problems does IPv4 cause today?

For example, I'm convinced that multiple layers of NAT44 (today's reality) cause problems, whose symptoms are often (from the end user's view) failed sessions that have to be repeated. These are *never* reported to any help desk and so don't appear in anybody's statistics - but they do detract from user experience and so presumably have an impact: lost or delayed 
business.

Others have mentioned the OPEX cost of diagnosing NAT-induced problems even with the enterprise.

What else?

Regards
    Brian Carpenter

On 30-Mar-22 16:22, Mark Smith wrote:
> 
> 
> On Wed, 23 Mar 2022, 01:55 JORDI PALET MARTINEZ, <jordi.palet=[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Eduard,____
> 
>     __ __
> 
> IPv6+NAT creates a lot of the issues that IPv4+NAT does, so why bother deploying IPv6 when you've already got the equivalent via IPv4 today?
> 
> 
> People need to understand why enterprises go to the expense of deploying technologies.
> 
> Technology is a means to an end, not the end itself. Technology in business either saves money or makes money for the business.
> 
> Enterprises in the 1990s didn't really deploy IPv4, they deployed global email and WWW access. Deploying IPv4 was the means to reaching those ends, because IPv4 underpinned them.
> 
> 
> So the questions to think about in the context of businesses and enterprises and IPv6 are:
> 
> - IPv6 is the technology means to an end, so what is or are the ends that are of value to a business, where IPv6 is the better underpinning technology than IPv4 to reach those ends?
> 
>     ____
>     __ __
>     On the other side, using an experimental protocol for production networks, in my opinion is a big “NO”.____
> 
>     __ __
> 
>     Regards,____
> 
>     Jordi____
> 
>     @jordipalet____
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     El 22/3/22, 13:04, "v6ops en nombre de Vasilenko Eduard" <[email-masked] <mailto:[email-masked]> en nombre de vasilenko.eduard=[email-masked] <mailto:[email-masked]>> escribió:____
> 
>     __ __
> 
>     Hi Jordi,____
> 
>     __ __
> 
>     I understand the desire to fix broken things. (I doubt it is possible)____
> 
>     But why NPT+ULA is not enough for MHMP now?____
> 
>     It is very similar to what Enterprises and small businesses have now.____
> 
>     They would be happy.____
> 
>     __ __
> 
>     Eduard____
> 
>     *From:*v6ops [mailto:[email-masked] <mailto:[email-masked]>] *On Behalf Of *JORDI PALET MARTINEZ
>     *To:* [email-masked] <mailto:[email-masked]>
>     *Subject:* Re: [v6ops] Thoughts about wider operational input____
> 
>     __ __
> 
>     You’re right. Let’s say it in a different way, as may be my first email was not clear on this.____
> 
>     __ __
> 
>     __1.__I don’t think we want again to repeat the NAT problems, so NPT is not a valid solution for me.____
> 
>     __2.__I think in the future almost every site could want to be multihomed, in some cases “n” links active, many other cases just as a backup.____
> 
>     __3.__This means that renumbering is not (probably) a valid choice in any cases.____
> 
>     __4.__Can we make PI work in such “huge scale” scenario?____
> 
>     __5.__Can source-address forwarding work and solve all that, or we need that and/or something else.____
> 
>     __ __
> 
>     Only if we solve this, organizations could learn that NAT with IPv6 
is not the solution, but something better that provides the same results, 
and no need to have “private” addresses, because the way NAT is offering a “different” addressing inside and outside is not NAT per-se, but statefull firewalling.____
> 
>     __ __
> 
>     Regards,____
> 
>     Jordi____
> 
>     @jordipalet____
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     El 22/3/22, 10:27, "v6ops en nombre de Ted Lemon" <[email-masked] <mailto:[email-masked]> en nombre de [email-masked] <mailto:[email-masked]>> escribió:____
> 
>     __ __
> 
>     Is it really hncp that we needed here?  I think the key tech we need is source-address-based forwarding, and babel i think has delivered that. Granted, getting that into soho routers is a problem. ____
> 
>     __ __
> 
>     On Tue, Mar 22, 2022 at 10:11 JORDI PALET MARTINEZ <jordi.palet=[email-masked] <mailto:[email-masked]>> wrote:____
> 
>         El 22/3/22, 9:31, "v6ops en nombre de Gert Doering" <[email-masked] <mailto:[email-masked]> en nombre de [email-masked] <mailto:[email-masked]>> escribió:
> 
>              Hi,
> 
>              > I agree with Jordi that multihoming is a genuine impediment. What isn't generally realised is that it's a problem of scale when considering at least 10,000,000 enterprises, much more than it's 
a problem of IPv6 itself.
>              My stance on this is that for "largely unmanaged 
SoHo networks" - which
>              Half of them do not want Internet access anyway, 
just access to their
>              then out to the Internet as a new TCP session (= 
could be done with
>              DMZ islands of upstream-provider-allocated space 
just fine).
>         http://www.theipv6company.com <http://www.theipv6company.com>
>         The IPv6 Company
> 
>         https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>____
> 
>     _______________________________________________ v6ops mailing list [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops> ____
> 
> 
>     http://www.theipv6company.com <http://www.theipv6company.com>
>     The IPv6 Company
> 
>     This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the 
contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.____
> 
>     _______________________________________________ v6ops mailing list [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops> ____
> 
> 
>     http://www.theipv6company.com <http://www.theipv6company.com>
>     The IPv6 Company
> 
>     This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the 
contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: "E. Marie Brierley" <[email-masked]>
Date: Wed, 30 Mar 2022 04:10:54 +0000

Great point. If you can quantify that issue by some means, I can add it to my comms to digital marketers (along with geolocation deterioration). Cart conversion is extremely low <3%, so any factor that can be incrementally quantified and improved is welcome in that audience.

E. Marie
________________________________
From: v6ops <[email-masked]> on behalf of Brian E Carpenter <[email-masked]>
Sent: Tuesday, March 29, 2022 9:06 PM
To: Mark Smith <[email-masked]>; JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
Cc: v6ops list <[email-masked]>
Subject: Re: [v6ops] Thoughts about wider operational input

What else?

Regards
    Brian Carpenter

SoHo networks" - which
just access to their
could be done with
just fine).

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Mar 2022 17:23:47 +1300

E. Marie,

I don't know how it can quantified; that might be an interesting research 
project.

I do see this (in a report from ~2015)[1]:
"Average Shopping Cart Abandonment Rate: BI Intelligence reports the average rate for ecommerce shopping cart abandonment across the globe is 71.2%."

A lot of that is of course users deciding not to buy. Does anybody know how to measure how much of it is due to session failure (per IP version)?

Regards
    Brian Carpenter

[1] https://guidingmetrics.com/content/ecommerce-industry-most-critical-metrics-kpis/

On 30-Mar-22 17:10, E. Marie Brierley wrote:
> Great point. If you can quantify that issue by some means, I can add it 
to my comms to digital marketers (along with geolocation deterioration). Cart conversion is extremely low <3%, so any factor that can be incrementally quantified and improved is welcome in that audience.
> 
> E. Marie
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* v6ops <[email-masked]> on behalf of Brian E Carpenter <[email-masked]>
> *Sent:* Tuesday, March 29, 2022 9:06 PM
> *To:* Mark Smith <[email-masked]>; JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
> *Cc:* v6ops list <[email-masked]>
>> On Wed, 23 Mar 2022, 01:55 JORDI PALET MARTINEZ, <jordi.palet=[email-masked] <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>> 
>>     Hi Eduard,____
>> 
>>     __ __
>> 
>>     El 22/3/22, 13:04, "v6ops en nombre de Vasilenko Eduard" <[email-masked] <mailto:[email-masked] <mailto:[email-masked]>> en nombre de vasilenko.eduard=[email-masked] <mailto:[email-masked] <mailto:[email-masked]>>> escribió:____
>> 
>>     __ __
>> 
>>     Hi Jordi,____
>> 
>>     __ __
>> 
>>     *From:*v6ops [mailto:[email-masked] <mailto:[email-masked] <mailto:[email-masked]>>] *On Behalf 
Of *JORDI PALET MARTINEZ
>>     *To:* [email-masked] <mailto:[email-masked] <mailto:[email-masked]>>
>>     El 22/3/22, 10:27, "v6ops en nombre de Ted Lemon" <[email-masked] <mailto:[email-masked] <mailto:[email-masked]>> en nombre de [email-masked] <mailto:[email-masked] 
<mailto:[email-masked]>>> escribió:____
>> 
>>     __ __
>> 
>>     Is it really hncp that we needed here?  I 
think the key tech we need is source-address-based forwarding, and babel i think has delivered that. Granted, getting that into soho routers is a problem. ____
>> 
>>     __ __
>> 
>>     On Tue, Mar 22, 2022 at 10:11 JORDI PALET MARTINEZ <jordi.palet=[email-masked] <mailto:[email-masked] <mailto:[email-masked]>>> wrote:____
>> 
>>         The problem is the same regardless of the "size" of the organization. The difference is that "today" most SMEs don't have that problem because they don't have PI, but it may turn the same when they realize that not being PI have renumbering issues  if changing the ISP. Of course, again, if we talk about a "small" 
SME, then may not be an issue, they only have 40 or 50 devices to renumber (your mileage will vary), not easy but not "terrible".
>>         El 22/3/22, 9:31, "v6ops en nombre de Gert Doering" <[email-masked] <mailto:[email-masked] <mailto:[email-masked]>> en nombre de [email-masked] <mailto:[email-masked] <mailto:[email-masked]>>> escribió:
>> 
>>              Hi,
>> 
>>              On 
Tue, Mar 22, 2022 at 11:42:12AM +1300, Brian E Carpenter wrote:
>>              My 
stance on this is that for "largely unmanaged 
>>              We 
need to work on our marketing regarding multihoming.  "What is it that
>>         [email-masked] <mailto:[email-masked] <mailto:[email-masked]>>
>>         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>>
>> 
>> 
>> 
>>         http://www.theipv6company.com <http://www.theipv6company.com> <http://www.theipv6company.com <http://www.theipv6company.com>>
>>         The IPv6 Company
>> 
>>         This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named 
above and further non-explicilty authorized disclosure, copying, distribution  or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of
> the contents of this information, even if partially, including attached 
files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
>>         [email-masked] <mailto:[email-masked] <mailto:[email-masked]>>
>>         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>>____
>> 
>>     _______________________________________________ v6ops mailing list [email-masked] <mailto:[email-masked] <mailto:[email-masked]>> 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>> ____
>> 
>> 
>>     http://www.theipv6company.com <http://www.theipv6company.com> <http://www.theipv6company.com <http://www.theipv6company.com>>
>>     The IPv6 Company
>> 
>>     This electronic message contains information which may be privileged or confidential. The information is intended to be 
for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use  of the contents of this information, even if partially, including attached files, is 
strictly prohibited and will be considered a criminal offense. If you are 
not the intended recipient be aware that any disclosure, copying, distribution or use of the
> contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you 
must reply to the original sender to inform about this communication and delete it.____
>> 
>>     _______________________________________________ v6ops mailing list [email-masked] <mailto:[email-masked] <mailto:[email-masked]>> 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>> ____
>> 
>> 
>>     http://www.theipv6company.com <http://www.theipv6company.com> <http://www.theipv6company.com <http://www.theipv6company.com>>
>>     The IPv6 Company
>> 
>>     This electronic message contains information which may be privileged or confidential. The information is intended to be 
for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use  of the contents of this information, even if partially, including attached files, is 
strictly prohibited and will be considered a criminal offense. If you are 
not the intended recipient be aware that any disclosure, copying, distribution or use of the
> contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you 
must reply to the original sender to inform about this communication and delete it.
>>     [email-masked] <mailto:[email-masked] <mailto:[email-masked]>>
>>     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: "E. Marie Brierley" <[email-masked]>
Date: Wed, 30 Mar 2022 04:26:27 +0000

Thanks for the info. Yes, there are multiple/many reasons for cart abandonment, hence the value of incremental improvement from any direction. Would be great to have a stat to work with for session interruption.

E. Marie
________________________________
From: Brian E Carpenter <[email-masked]>
Sent: Tuesday, March 29, 2022 9:23 PM
To: E. Marie Brierley <[email-masked]>; Mark Smith <[email-masked]>; JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
Cc: v6ops list <[email-masked]>
Subject: Re: [v6ops] Thoughts about wider operational input

E. Marie,

Regards
    Brian Carpenter

Of *JORDI PALET MARTINEZ

---

From: Chongfeng Xie <[email-masked]>
Date: Wed, 30 Mar 2022 14:31:30 +0800

Hi， Mark，
Some enterprises do not want to expose their real address in the network to the outside, so they will use NAT, whether nat44 or nat64 or even nat66 in the future. Therefore, NAT may always exist with the needs of customers.

The technology itself is not right or wrong. It is inappropriate to directly state whether a technology is good or bad, but whether the technology is appropriate for specific scenarios. You said there was a lot of issues with IPv6+NAT，under what scenario? What's are the issues ? Is it a stateless IPv6+NAT or a stateful IPv6+NAT?

Thanks
Chongfeng

> 2022年3月30日 上午11:22，Mark Smith <[email-masked]> 写道：
> 
> 
> 
> El 22/3/22, 13:04, "v6ops en nombre de Vasilenko Eduard" <[email-masked] <mailto:[email-masked]> en nombre de vasilenko.eduard=[email-masked] <mailto:[email-masked]>> escribió:
> 
>  
> 
> Hi Jordi,
> 
>  
> 
> From: v6ops [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of JORDI PALET MARTINEZ
> To: [email-masked] <mailto:[email-masked]>
> El 22/3/22, 10:27, "v6ops en nombre de Ted Lemon" <[email-masked] <mailto:[email-masked]> en nombre de [email-masked] <mailto:[email-masked]>> escribió:
> 
>  
> 
> On Tue, Mar 22, 2022 at 10:11 JORDI PALET MARTINEZ <jordi.palet=[email-masked] <mailto:[email-masked]>> wrote:
> 
> http://www.theipv6company.com <http://www.theipv6company.com/>
> The IPv6 Company
> 
> _______________________________________________ v6ops mailing list [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> 
> http://www.theipv6company.com <http://www.theipv6company.com/>
> The IPv6 Company
> 
> _______________________________________________ v6ops mailing list [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> http://www.theipv6company.com <http://www.theipv6company.com/>
> The IPv6 Company
>

---

From: Brian Carpenter <[email-masked]>
Date: Wed, 30 Mar 2022 19:51:14 +1300

Hi,
Nothing has changed. When a NAT loses state (e.g. due to overload) user
sessions break & servers lose business. We lack statistics on this, so it's
a hidden cost to business.

The arguments for address hiding are pretty weak IMHO and mainly come from
NAT salespeople, but unfortunately they are widely believed.

Regards,
    Brian Carpenter
    (via tiny screen & keyboard)

On Wed, 30 Mar 2022, 19:32 Chongfeng Xie, <[email-masked]> wrote:

> Hi， Mark，
> Some enterprises do not want to expose their real address in the network
> to the outside, so they will use NAT, whether nat44 or nat64 or even nat66
> in the future. Therefore, NAT may always exist with the needs of customers.
>
> The technology itself is not right or wrong. It is inappropriate to
> directly state whether a technology is good or bad, but whether the
> technology is appropriate for specific scenarios. You said there was a lot
> of issues with IPv6+NAT，under what scenario? What's are the issues ? Is
> it a stateless IPv6+NAT or a stateful IPv6+NAT?
>
> Thanks
> Chongfeng
>
>
> Technology is a means to an end, not the end itself. Technology in
> business either saves money or makes money for the business.
>
>> Only if we solve this, organizations could learn that NAT with IPv6 is
>> not the solution, but something better that provides the same results, and
>> no need to have “private” addresses, because the way NAT is offering a
>> Maybe the terminology is not the most appropriate and we should talk
>> about "organizations", because there are many types of networks that have
>> the same problem and those are not enterprises (such as government sites,
>> NGOs, etc.).
>>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 30 Mar 2022 09:25:05 +0200

I bet that in the majority of the cases for enterprises willing to continue using NAT with IPv6, the reasons are:
We are using to it in IPv4, why changing it in IPv6 (mental change when adopting IPv6 = lack of proper training).
Wrong perception that NAT (and hiding addresses) = security.
Vendors of equipment continue to lie and say “yes” to customers when they ask for NAT66, even if they are supporting an experimental protocol (NPT) and they don’t tell customers “yes we have it, but note that it is an experimental protocol, so not proven interoperability and you’re exposed to consequences than we don’t know yet with apps or services, and same problems as in NAT44”.

Regards,

Jordi

@jordipalet

El 30/3/22, 8:32, "v6ops en nombre de Chongfeng Xie" <[email-masked] en nombre de [email-masked]> escribió:

Hi， Mark，

Thanks

Chongfeng

 

On Wed, 23 Mar 2022, 01:55 JORDI PALET MARTINEZ, <jordi.palet=[email-masked]> wrote:

Hi Eduard,

This.

 

 

Regards,

Mark.

 

Regards,

Jordi

@jordipalet

Hi Jordi,

They would be happy.

Eduard

Regards,

Jordi

@jordipalet

Regards,
Jordi
@jordipalet

    Hi,

    What is "an enterprise"?

    Gert Doering
            -- NetMaster

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 30 Mar 2022 10:32:23 +0000 (UTC)

Brian,
>  Others have mentioned the OPEX cost of diagnosing NAT-induced problems even with the enterprise.
As someone who has been involved with diagnosing problems on enterprise networks for 30+ years, I can tell you the complexity of finding and solving problems with IPv6, adds a huge new and glorious dimension to troubleshooting.
Don't get me wrong, I am a complete IPv6 proponent.  I am just saying that if ease of diagnostics is what you are looking for, IMHO, that is exactly the opposite of what is likely to happen.  
For example, take the scenario below:
- User is connecting via a home network routed through a broadband provider which supports both IPv4 and IPv6.  This home network uses a NAT.
Let's assume the user has the following IP addresses:
1. IPv6 Address. . . . . :2a02:c7d:500e:f900:f5:8404:5e0:430eGlobal Unicast IPv6 : routable over the Internet 
2. IPv6 Address. .   . . :fd4f:f7d8:2459:0:f5:8404:5e0:430eUnique Local Unicast (ULA) IPv6 :not routable over Internet
3. Temporary IPv6 Address:2a02:c7d:500e:f900:a53a:5a06:130b:a2ffPrivacy Global Unicast IPv6 :routable over the Internet 
4. Temporary IPv6 Address:fd4f:f7d8:2459:0:a53a:5a06:130b:a2ffPrivacy ULA IPv6 :not routable over the Internet 
5. Link-local IPv6 Address:fe80::f5:8404:5e0:430e%13Private Interface IPv6: not routable over the Internet 
6. IPv4 Address. . .  . . :192.168.0.6Site Local GUA IPv4 : not routable over the Internet 
The NAT has the external IPv4 address: 156.21.33.134 (IPv4 GUA: made up address)
Today, most enterprises do not have GUA or ULA IPv6 addresses but this will change in the next 5 years.  The above (other than the IPv4 NAT address) are real addresses from an IPConfig on my laptop on a network in the RIPE region. (This is an interesting use of ULAs, BTW.  Their DNS appears to work over ULA.)
So, if this user calls the network Help Desk of an enterprise and says "I have a problem connecting / with my application / with response time" and the Help Desk first wants to know the IP address the user has, this becomes quite interesting.  Which exact IP address are we talking about?  I have actually started a paper to allow enterprises to cope with this scenario, if anyone would like to help / make it into an Internet draft, please let me know.  I will actually start a new email thread with drafts I believe need to be written to help enterprises.
Now, before people start telling me to convert to an IPv6-only network and such like, please stop.   Enterprises move at a snails pace and they are very risk-averse.   I can guarantee you that talk like that will only get you completely not listened to.  
Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360 

What else?

Regards
    Brian Carpenter

SoHo networks" - which
just access to their
could be done with
just fine).

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Wed, 30 Mar 2022 13:18:23 +0200

Hi,

> On 30. Mar 2022, at 12:32, [email-masked] wrote:
> 
> Brian,
> 

Totally agreed, but IPv6 also eliminate a whole class of problems with overlapping RCF1918 spaces and unsolvable merging and integration scenarios. 

> Now, before people start telling me to convert to an IPv6-only network and such like, please stop.   Enterprises move at a snails pace and they are very risk-averse.   I can guarantee you that talk…

I think it really depends on the use-case.

- If you try to sell IPv6 only in office networks, not getting listend to is rather a best case assumption.
- If you are setting up new server landscapes and are already out of RFC1918 space, IPv6 only becomes a serious consideration (perhaps with the addition of dual-stack load balancers and egress NAT64)  

The point is: IPv6 can be presented as a tool to solve problems or as a technology you may need to adopt in some distant future. Start with the former, only use the later as supporting argument. 

AVE!
   Philipp S. Tiesel

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 30 Mar 2022 13:36:52 +0000

Hi Mark,
NPT+ULA are much better than NAPT44 (no port translation), but not ideal (applications may encode address too).
The problem is that Business (from small to big) needs Carrier’s redundancy.
It is mandatory and NAPT44 is the solution for it now.
The “normal” solution needs heavy modification in “Default address Selection”, “ND”, prefix distribution (HNCP?),
That is nobody interesting to push.
Hence, NPT is the only alternative. That would be greatly welcomed by Businesses that are comfortable with NAT.
Eduard
From: v6ops [mailto:[email-masked]] On Behalf Of Mark Smith
Sent: Wednesday, March 30, 2022 6:22 AM
To: JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
Cc: v6ops list <[email-masked]>
Subject: Re: [v6ops] Thoughts about wider operational input

On Wed, 23 Mar 2022, 01:55 JORDI PALET MARTINEZ, <jordi.palet=[email-masked]<mailto:[email-masked]>> wrote:
Hi Eduard,

This.

Regards,
Mark.

Regards,
Jordi
@jordipalet

Hi Jordi,

Eduard
From: v6ops [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of JORDI PALET MARTINEZ
Sent: Tuesday, March 22, 2022 12:34 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] Thoughts about wider operational input

Regards,
Jordi
@jordipalet

Regards,
Jordi
@jordipalet

    Hi,

    What is "an enterprise"?

    Gert Doering
            -- NetMaster

---

From: "Ackermann, Michael" <[email-masked]>
Date: Wed, 30 Mar 2022 14:32:03 +0000

Great points Jordi!

IMHO, the biggest problem is #2  (appropriately designated 😊)
This is very old thinking and Security professionals will say this is no longer a good idea for any security reason.    But yet this thinking persists.    To the extent that we can educate these thoughts away,  and make enterprises realize that NATs are not desirable,  I believe that would be effective.

Thanks

Mike

From: v6ops <[email-masked]> On Behalf Of JORDI PALET MARTINEZ
Sent: Wednesday, March 30, 2022 3:25 AM
To: v6ops list <[email-masked]>
Subject: Re: [v6ops] Thoughts about wider operational input

[External email]

  1.  We are using to it in IPv4, why changing it in IPv6 (mental change when adopting IPv6 = lack of proper training).
  2.  Wrong perception that NAT (and hiding addresses) = security.
  3.  Vendors of equipment continue to lie and say “yes” to customers when they ask for NAT66, even if they are supporting an experimental protocol (NPT) and they don’t tell customers “yes we have it, but note that it is an experimental protocol, so not proven interoperability and you’re exposed to consequences than we don’t know yet with apps or services, and same problems as in NAT44”.

Regards,
Jordi
@jordipalet

El 30/3/22, 8:32, "v6ops en nombre de Chongfeng Xie" <[email-masked]<mailto:[email-masked]> en nombre de [email-masked]<mailto:[email-masked]>> escribió:

Hi， Mark，

Thanks
Chongfeng

2022年3月30日 上午11:22，Mark Smith <[email-masked]<mailto:[email-masked]>> 写道：

This.

Regards,
Mark.

Regards,
Jordi
@jordipalet

Hi Jordi,

Eduard

Regards,
Jordi
@jordipalet

Regards,
Jordi
@jordipalet

    Hi,

    What is "an enterprise"?

    Gert Doering
            -- NetMaster

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com<http://www.theipv6company.com/>
The IPv6 Company

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com<http://www.theipv6company.com/>
The IPv6 Company

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com<http://www.theipv6company.com/>
The IPv6 Company

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 30 Mar 2022 17:02:49 +0200

To demonstrate how NAT is not security, you just need to enable Teredo or any other UDP tunneling traversing the NAT, so the security guys can see that without any special config in the NAT, you can dig a whole on it (Teredo Navalis = Shipworm).

Regards,

Jordi

@jordipalet

This message was sent securely using Zix® 

El 30/3/22, 16:32, "Ackermann, Michael" <MAckermann=[email-masked]> escribió:

Great points Jordi! 

Thanks

Mike

[External email] 

1)      We are using to it in IPv4, why changing it in IPv6 (mental change when adopting IPv6 = lack of proper training).

2)      Wrong perception that NAT (and hiding addresses) = security.

3)      Vendors of equipment continue to lie and say “yes” to customers when they ask for NAT66, even if they are supporting an experimental protocol (NPT) and they don’t tell customers “yes we have it, but note that it is an experimental protocol, so not proven interoperability and you’re exposed to consequences than we don’t know yet with apps or services, and same problems as in NAT44”.

Regards,

Jordi

@jordipalet

Hi， Mark，

Thanks

Chongfeng

 

Hi Eduard,

This.

 

 

Regards,

Mark.

 

Regards,

Jordi

@jordipalet

Hi Jordi,

They would be happy.

Eduard

Regards,

Jordi

@jordipalet

Regards,
Jordi
@jordipalet

    Hi,

    What is "an enterprise"?

    Gert Doering
            -- NetMaster

This message was secured by Zix®.

---

From: Joe Maimon <[email-masked]>
Date: Wed, 30 Mar 2022 11:56:01 -0400

Ackermann, Michael wrote:
> <http://www.zixcorp.com/get-started/>
>
>
> Great points Jordi!
>
> This is very old thinking and Security professionals will say this is 
> no longer a good idea for any security reason.    But yet this 
> thinking persists.    To the extent that we can educate these thoughts 
> away,  and make enterprises realize that NATs are not desirable,  I 
> believe that would be effective.
>
> Thanks
>
> Mike
>

I dont see any mention that Enterprises like abstraction of addressing 
that places them in control of it, not any vendor or even some external 
standards body that may or may not have their interests in mind and that 
they may or may not have any interest in participating.

NAT is indeed a security layer, because it fails closed and requires 
explicit permission to allow traffic. Enterprises like that.

You will not succeed in educating Enterprises why NAT's are undesirable 
until your understand the reasons they desire them.

Joe

> *From:* v6ops <[email-masked]> *On Behalf Of * JORDI PALET 
> MARTINEZ
> *Sent:* Wednesday, March 30, 2022 3:25 AM
> *To:* v6ops list <[email-masked]>
> I bet that in the majority of the cases for enterprises willing to 
> continue using NAT with IPv6, the reasons are:
>
>  1. We are using to it in IPv4, why changing it in IPv6 (mental change
>     when adopting IPv6 = lack of proper training).
>  3. Vendors of equipment continue to lie and say “yes” to customers
>     when they ask for NAT66, even if they are supporting an
>     experimental protocol (NPT) and they don’t tell customers “yes we
>     have it, but note that it is an experimental protocol, so not
>     proven interoperability and you’re exposed to consequences than we
>     don’t know yet with apps or services, and same problems as in NAT44”.
>
> Regards,
>
> Jordi
>
> @jordipalet
>
> El 30/3/22, 8:32, "v6ops en nombre de Chongfeng Xie" 
> <[email-masked] <mailto:[email-masked]> en nombre de 
> [email-masked] <mailto:[email-masked]>> escribió:
>
> Hi，Mark，
>
> Some enterprises do not want to expose their real address in the 
> network to the outside, so they will use NAT, whether nat44 or nat64 
> or even nat66 in the future. Therefore, NAT may always exist with the 
> needs of customers.
>
> technology is appropriate for specific scenarios. You said there was a 
> lot of issues with IPv6+NAT，under what scenario? What's are the 
> issues ? Is it a stateless IPv6+NAT or a stateful IPv6+NAT?
>
> Thanks
>
> Chongfeng
>
>     2022年3月30日 上午11:22，Mark Smith <[email-masked]
>     <mailto:[email-masked]>> 写 道：
>
>     On Wed, 23 Mar 2022, 01:55 JORDI PALET MARTINEZ,
>     <jordi.palet=[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Hi Eduard,
>
>         What I meant is that I will like to avoid the issues that NAT
>         creates for apps. We must aim for something better.
>
>     This.
>
>     IPv6+NAT creates a lot of the issues that IPv4+NAT does, so why
>     bother deploying IPv6 when you've already got the equivalent via
>     IPv4 today?
>
>     Enterprises in the 1990s didn't really deploy IPv4, they deployed
>     global email and WWW access. Deploying IPv4 was the means to
>     reaching those ends, because IPv4 underpinned them.
>
>     - IPv6 is the technology means to an end, so what is or are the
>     ends that are of value to a business, where IPv6 is the better
>     underpinning technology than IPv4 to reach those ends?
>
>         On the other side, using an experimental protocol for
>         production networks, in my opinion is a big “NO”.
>
>         Regards,
>
>         Jordi
>
>         @jordipalet
>
>         El 22/3/22, 13:04, "v6ops en nombre de Vasilenko Eduard"
>         <[email-masked] <mailto:[email-masked]> en
>         nombre de vasilenko.eduard=[email-masked]
>         <mailto:[email-masked]>> escribió:
>
>         Hi Jordi,
>
>         *From:* v6ops [mailto:[email-masked]
>         <mailto:[email-masked]>] *On Behalf Of *JORDI PALET
>         MARTINEZ
>         1.I don’t think we want again to repeat the NAT problems, so
>         NPT is not a valid solution for me.
>
>         2.I think in the future almost every site could want to be
>         multihomed, in some cases “n” links active, many other cases
>         just as a backup.
>
>         3.This means that renumbering is not (probably) a valid choice
>         in any cases.
>
>         4.Can we make PI work in such “huge scale” scenario?
>
>         5.Can source-address forwarding work and solve all that, or we
>         need that and/or something else.
>
>         Only if we solve this, organizations could learn that NAT with
>         IPv6 is not the solution, but something better that provides
>         the same results, and no need to have “private” addresses,
>         because the way NAT is offering a “different” addressing
>         inside and outside is not NAT per-se, but statefull firewalling.
>
>         Regards,
>
>         Jordi
>
>         @jordipalet
>
>         El 22/3/22, 10:27, "v6ops en nombre de Ted Lemon"
>         <[email-masked] <mailto:[email-masked]> en
>         nombre de [email-masked] <mailto:[email-masked]>> escribió:
>
>         Is it really hncp that we needed here?  I think the key tech
>         we need is source-address-based forwarding, and babel i think
>         has delivered that. Granted, getting that into soho routers is
>         a problem.
>
>         On Tue, Mar 22, 2022 at 10:11 JORDI PALET MARTINEZ
>         <jordi.palet=[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>             Maybe the terminology is not the most appropriate and we
>             should talk about "organizations", because there are many
>             types of networks that have the same problem and those are
>             not enterprises (such as government sites, NGOs, etc.).
>
>             The problem is the same regardless of the "size" of the
>             organization. The difference is that "today" most SMEs
>             don't have that problem because they don't have PI, but it
>             may turn the same when they realize that not being PI have
>             renumbering issues if changing the ISP. Of course, again,
>             if we talk about a "small" SME, then may not be an issue,
>             they only have 40 or 50 devices to renumber (your mileage
>             will vary), not easy but not "terrible".
>
>             On the rest of Gert comments, definitively I agree, and
>             specially on our big mistake not working further on HNCP.
>
>             Regards,
>             Jordi
>             @jordipalet
>
>
>
>             El 22/3/22, 9:31, "v6ops en nombre de Gert Doering"
>             <[email-masked] <mailto:[email-masked]> en
>             nombre de [email-masked] <mailto:[email-masked]>> escribió:
>
>                 Hi,
>
>             impediment. What isn't generally realised is that it's a
>             problem of scale when considering at least 10,000,000
>             enterprises, much more than it's a problem of IPv6 itself.
>
>                 What is "an enterprise"?
>
>             This electronic message contains information which may be
>             privileged or confidential. The information is intended to
>             be for the exclusive use of the individual(s) named above
>             and further non-explicilty authorized disclosure, copying,
>             distribution or use of the contents of this information,
>             even if partially, including attached files, is strictly
>             prohibited and will be considered a criminal offense. If
>             you are not the intended recipient be aware that any
>             disclosure, copying, distribution or use of the contents
>             of this information, even if partially, including attached
>             files, is strictly prohibited, will be considered a
>             criminal offense, so you must reply to the original sender
>             to inform about this communication and delete it.
>
>
>
>         _______________________________________________ v6ops mailing
>         list [email-masked] <mailto:[email-masked]>
>         This electronic message contains information which may be
>         privileged or confidential. The information is intended to be
>         for the exclusive use of the individual(s) named above and
>         further non-explicilty authorized disclosure, copying,
>         distribution or use of the contents of this information, even
>         if partially, including attached files, is strictly prohibited
>         and will be considered a criminal offense. If you are not the
>         intended recipient be aware that any disclosure, copying,
>         distribution or use of the contents of this information, even
>         if partially, including attached files, is strictly
>         prohibited, will be considered a criminal offense, so you must
>         _______________________________________________ v6ops mailing
>         list [email-masked] <mailto:[email-masked]>
>         This electronic message contains information which may be
>         privileged or confidential. The information is intended to be
>         for the exclusive use of the individual(s) named above and
>         further non-explicilty authorized disclosure, copying,
>         distribution or use of the contents of this information, even
>         if partially, including attached files, is strictly prohibited
>         and will be considered a criminal offense. If you are not the
>         intended recipient be aware that any disclosure, copying,
>         distribution or use of the contents of this information, even
>         if partially, including attached files, is strictly
>         prohibited, will be considered a criminal offense, so you must
> This electronic message contains information which may be privileged 
> or confidential. The information is intended to be for the exclusive 
> use of the individual(s) named above and further non-explicilty 
> authorized disclosure, copying, distribution or use of the contents of 
> this information, even if partially, including attached files, is 
> strictly prohibited and will be considered a criminal offense. If you 
> are not the intended recipient be aware that any disclosure, copying, 
> distribution or use of the contents of this information, even if 
> partially, including attached files, is strictly prohibited, will be 
> considered a criminal offense, so you must reply to the original 
> sender to inform about this communication and delete it.
>
>
> The information contained in this communication is highly confidential 
> and is intended solely for the use of the individual(s) to whom this 
> communication is directed. If you are not the intended recipient, you 
> are hereby notified that any viewing, copying, disclosure or 
> distribution of this information is prohibited. Please notify the 
> sender, by electronic mail or telephone, of any unintended receipt and 
> delete the original message without making any copies.
>
> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan 
> are nonprofit corporations and independent licensees of the Blue Cross 
> and Blue Shield Association.
>
>
>
> This message was secured by *Zix <http://www.zixcorp.com>^® *.
>
>

---

From: Joe Maimon <[email-masked]>
Date: Wed, 30 Mar 2022 11:56:59 -0400

JORDI PALET MARTINEZ wrote:
>
> To demonstrate how NAT is not security, you just need to enable Teredo 
> or any other UDP tunneling traversing the NAT, so the security guys 
> can see that without any special config in the NAT, you can dig a 
> whole on it (Teredo Navalis = Shipworm).
>
> Regards,
>
> Jordi
>
> @jordipalet
>

And then you need to demonstrate how the equivalent would not happen on 
IPv6.

Joe

---

From: Fred Baker <[email-masked]>
Date: Wed, 30 Mar 2022 09:31:28 -0700

> On Mar 29, 2022, at 3:38 PM, Xipengxiao <[email-masked]> wrote:
> 

Thanks!

---

From: "Ackermann, Michael" <[email-masked]>
Date: Wed, 30 Mar 2022 17:06:51 +0000

That would be compelling!!!!
Good idea.  

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Joe Maimon
Sent: Wednesday, March 30, 2022 11:57 AM
To: JORDI PALET MARTINEZ <jordi.palet=[email-masked]>; v6ops list <[email-masked]>
Subject: Re: [v6ops] Thoughts about wider operational input

[External email]

> whole on it (Teredo Navalis = Shipworm).

And then you need to demonstrate how the equivalent would not happen on IPv6.

Joe

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 30 Mar 2022 20:27:20 +0200

Because if you don't have NAT, you are forced to properly configure a firewall.

With a NAT, many don't even have a firewall or is not sufficiently well configured.

Regards,
Jordi
@jordipalet

El 30/3/22, 17:58, "v6ops en nombre de Joe Maimon" <[email-masked] en nombre de [email-masked]> escribió:

    Joe

---

From: Simon <[email-masked]>
Date: Wed, 30 Mar 2022 21:11:44 +0100

> The technology itself is not right or wrong. It is inappropriate to directly state whether a technology is good or bad, but whether the technology is appropriate for specific scenarios. You said th…

Any form of NAT breaks things<period> That’s the short answer.

Longer answer, any protocol that embeds addresses in it gets broken - e.g. during session setup one end tells the other, please contact me at address X and port Y. That is quite common once you get past a basic “open connection, squirt some data, close session”. Examples that come immediately to mind :

VoIP: phone registers with an exchange. The exchange need to be able to directly call the phone on a control port (typically the same one used to register) to tell it when a call comes in. The phone then needs to tell the exchange what address and port it wants the voice (and/or video) stream sent to. That stream may come from the exchange, or in the more general case it could come from elsewhere - e.g the two end points exchange the voice stream directly without routing it via the exchange. That is how SIP is designed to work - but in my limited experience is never done because it’s too broken by NAT for it to ever work reliably, instead VoIP providers typically have to provide a proxy service that the phone talks to, and the proxy service has to manage de-mangling stuff NAT broke.

The details don’t come to mind right now, but I believe file sharing in both Windows and Unix (NFS?) tend to have a master (control) service with which the clients talk, and then the actual data transfer is done over a separate connection negotiated between the client and server control processes. So the server tells the client to connect to a specific address and port for the data connection - which is broken by NAT.

FTP: By default uses separate connections for control and data transfer, and needs either an ALG to modify address/port pairs in the control packets, or the client use a specific mode (passive mode ?) to avoid the problem. I vaguely recall the server can contact the client as well - it’s a long time since I delved into the internals of FTP sessions !

And then there are distributed applications - BitTorrent is one well known one that comes to mind. Peers need to tell “the cloud” where they can be contacted by other peers - also broken by NAT.

All of these problems can be worked around to some degree or other, but the common factors are :
They don’t work (typically at all) through NAT without some help. With Bittorrent peers, typically there’s a whole config section to tell it what NAT it is behind, ditto for (e.g.) Asterisk as a VoIP switch. With some NAT implementations it’s impossible to make some fo them work - see below.
They all involve developers, and support people, putting effort into implementing the workaround code and support (e.g. adding the settings to the config pages) and users waste effort getting them set up right. All effort that could be better put to productive use rather than fighting broken networks.

A few years ago I came across a NAT implementation that defied all attempts to get VoIP through it. Many (IPv4 implementations) try and preserve the port number if that port isn’t already mapped for another internal device, many attempt to keep the mapping stable (i.e. the device appears as the same address and port to all outside devices). These are relatively easy to work through and the device can work out what it needs to do with (e.g.) STUN.
But one implementation really had me wondering WTF - and the vendor straight up said “it’s for security” and didn’t consider “but pity it means some of your devices can’t work properly” as any sort of problem. This implementation actively randomised the port mapping for every connection - not just a different mapping for each outside device an internal device connects with, but on each connection so once a UDP mapping timed out, on the next connection the client was guaranteed to get a different mapping. So while some vendors at least try and make NAT as least damaging as they can, others have gone out of their way to make it truly crippling - unless the sole purpose of the network is to allow a web browser or email client to connect to an outside server.
You remember things like that, and to this day I do my utmost to avoid using or recommending Zyxel kit.

On 30 Mar 2022, at 16:56, Joe Maimon <[email-masked]> wrote:

> NAT is indeed a security layer, because it fails closed and requires explicit permission to allow traffic. Enterprises like that.

NAT does no more than even the most basic packet-filter firewall can do if set to a  default of “deny inbound, permit outbound”. How many decades have all the relevant OSs supported at least a basic packet filter ? What’s more, a basic packet filter needs less resources (no connection tracking table) than a NAT gateway - a stateful firewall will need (I think) a similar level of resources in terms of tracking connections (perhaps a bit less as it doesn’t need to store two address/port pairs for the inside end of each connection like a NAT gateway does).

Simon

---

From: Joe Maimon <[email-masked]>
Date: Wed, 30 Mar 2022 16:16:17 -0400

> Because if you don't have NAT, you are forced to properly configure a firewall.

That is backwards.

NAT requires state management to operate. What exactly is forcing the 
existence of a firewall, let alone its proper configuration?

NAT is an operational requirement. You have it because without it 
something does not work the way you want it to.

Firewalls are a security requirement. You implement them because without 
it something you do not want to work might or even probably will.

Take car insurance as an example. Even where not legally mandated 
(anywhere?) its an obvious practical necessity. Yet, uninsured drivers 
and cars abound on the road. Because lack of insurance doesnt interfere 
with the ability to operate the vehicle. Its not an operational requirement.

Operational requirements meet my definition of "force". Security 
requirements, decidedly less so as has been painfully and universally 
obvious for decades. Or should be.

As far as the proper configuration of one? Proving your NAT is 
sufficiently properly configured. Easy. The firewall? Impractical to 
impossible, its a negative theorum.

Restated correctly: Without NAT, you must choose to implement a firewall 
for it to exist. Perhaps properly. Likely not. Fixed that for you.

Or:

Because if you don't have NAT, unless you choose to properly configure a 
firewall, you will not have one either, properly configured or otherwise.

> With a NAT, many don't even have a firewall or is not sufficiently well configured.

Please explain how removing the near universal existence of NAT improves 
this situation. Do you somehow believe that there will be the equivalent 
or even greater number of deployments and users who actively choose to 
deploy firewalling as a result of the global routability of their 
addressing and the lack of NAT, and that now having made that choice it 
will as matter of course be followed by the choice to do so in the 
utmost correct, stringent and sufficient fashion? Farcical.

At least with the existence of NAT there also exists some level of state 
management and unsolicited incoming traffic constraints from reaching 
the internal network nodes. By default, by dint of them being 
operationally on the internet.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 31 Mar 2022 10:15:02 +1300

Jordi,

As we all know, home gateways that support IPv6 are shipped with a quite adequate default firewall configuration. Is there a good specification for a default firewall configuration for an SME CE router?

Probably this isn't realistic for large enterprises?

    Brian
>      And then you need to demonstrate how the equivalent would not happen on
confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is 
strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete 
it.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 31 Mar 2022 10:18:55 +1300

On 31-Mar-22 09:16, Joe Maimon wrote:
...

> operationally on the internet.

As I just noted, the same is true with IPv6-capable domestic CEs in the
complete absence of NAT66 or NPTv6. By default. Why can that not be true
for enterprise CEs?

     Brian

---

From: Joe Maimon <[email-masked]>
Date: Wed, 30 Mar 2022 17:22:33 -0400

Simon wrote:
> On 30 Mar 2022, at 07:31, Chongfeng Xie <[email-masked] 
>> technology is appropriate for specific scenarios. You said there was 
>> a lot of issues with IPv6+NAT，under what scenario? What's are the 
> Longer answer, any protocol that embeds addresses in it gets broken - 
> e.g. during session setup one end tells the other, please contact me 
> at address X and port Y. That is quite common once you get past a 
> basic “open connection, squirt some data, close session”. Examples 
> that come immediately to mind :

In OSI speak thats a layering violation. An upper level protocol 
incorporates details and assumptions about lower layers as part of its 
operations. Unfortunately, TCP/IP and its application protocols are rife 
with them. Well more than one should expect were proper attention have 
been given to ensure that there was absolutely no equivalent proper way 
to do it.

Just because its common and convenient and usually works or can be made 
to work does not make it correct. Worse, sometimes its considered quite 
clever. PMTUD comes to mind.

<snip>
>
> They all involve developers, and support people, putting effort into 
> implementing the workaround code and support (e.g. adding the settings 
> to the config pages) and users waste effort getting them set up right. 
> All effort that could be better put to productive use rather than 
> fighting broken networks.

In theory, the protocols are broken. If they hadnt taken the easy way 
out, we would not have to work around so many of them.

<snip>
>
>
>
> NAT does no more than even the most basic packet-filter firewall can 
> do if set to a  default of “deny inbound, permit outbound”.

Correct. Which is a good thing. The point is that if turning off NAT 
means no internet communications, you can be fairly certain it will be 
on. No such assumption exist without NAT.

IPv4 NAPT comes a lot closer to secure by default than IPv6 with basic 
state aware packet filters.

> How many decades have all the relevant OSs supported at least a basic 
> packet filter ?

NAT was widespread well before state tracking packet filters were.

> What’s more, a basic packet filter needs less resources (no connection 
> tracking table) than a NAT gateway - a stateful firewall will need (I 
> think) a similar level of resources in terms of tracking connections 
> (perhaps a bit less as it doesn’t need to store two address/port pairs 
> for the inside end of each connection like a NAT gateway does).
>
>
> Simon
>
>
RAM is cheap. Lookup per packet is expensive.

It should be obvious that state-less packet filters are rarely useful or 
even used on the internet of today.

Thats because along with not keeping state, they also require you to do 
things like this if you want your users to browse the web.

access-list out permit any any tcp port 80
access-list in permit any tcp port 80 any port range 1025-65535

Not very convenient or secure.

I know when I can use them and its for situations where the traffic 
flows are extremely well and tightly defined.

Keeping state is what allows a packet filter to have meaningful security 
AND still allow practical bi-directional traffic.

And at that point its the same tracking code as the translation feature 
would need. Not having to munch and mangle bits is some amount of 
performance win, but thats not what you were describing.

State-less packet filters are not germain to an IPv6 vs NAT security 
discussion.

Joe

---

From: Joe Maimon <[email-masked]>
Date: Wed, 30 Mar 2022 17:24:48 -0400

Brian E Carpenter wrote:
> Jordi,
>
> As we all know, home gateways that support IPv6 are shipped with a 
> quite adequate default firewall configuration. 

Which is turned on. And never gets turned off and left off without 
anyone noticing or caring.

Joe

---

From: Joe Maimon <[email-masked]>
Date: Wed, 30 Mar 2022 18:07:19 -0400

> complete absence of NAT66 or NPTv6. By default. Why can that not be true

I thought you were expressing some sarcasm. The same is completely 
untrue of IPv6 CPE.

Of course we fully expect (and hope for) CPE to incorporate a properly 
functioning firewall, IPv4 and IPv6, whether for end users or 
enterprises. And we want it to have secure defaults.

The problem is that in IPv6, any and all security functionality is 
orthogonal to the primary purpose of the CPE, which is to pass packets 
so the user gets to use the internet.

Enterprises are with near complete certainty going to need extensive 
management and featuresets on that firewall. Their requirements from a 
firewall go far far beyond network translation features, of which there 
are many and they make use of them, but thats beside the point.

The point I have been trying to make is that with NAPT44 in IPv4 as it 
is commonly deployed today, when the "firewall" is off, so is the 
internet. That is an inherent level of security absent in IPv6 as 
commonly deployed.

NAT fails securely. IPv6 firewalls do not.

In the absence of this basic level of security by default, ever greater 
rigorous and vigorous attention needs to be given to the security 
features and functionality as shipped to consumers, who are unlikely to 
do anything beyond plug it in and turn it on.

I question whether such efforts are enough to bridge that gap. History 
suggests that is unlikely. And the fact that they are now required is a 
step backwards in time.

These are the same devices that oops, ship with backdoor passwords and 
otherwise glaring security defects. All the time.

I further note that with such a setup, communication issues 
troubleshooting will likely start with "turn off the firewall", as it 
does today on most desktops. Users are unlikely to turn it back on after 
that at any point. So your CPE must also come with a turn back on timer 
feature. Standardize that. Worse, this is a moving target, and as 
before, its orthogonal, tangential, a cost center.

Typical IPv6 users are not likely to be any more security aware and 
conscious than IPv4 users are now. They are the same users.

The same is true for the vendors whose customers are those users.

Joe

---

From: Mark Andrews <[email-masked]>
Date: Thu, 31 Mar 2022 10:45:33 +1100

> On 31 Mar 2022, at 02:56, Joe Maimon <[email-masked]> wrote:
> 
> 
> 

The fix is the same in both protocols.  Install a FIREWALL and properly configure it to block port 3544.
NAT is not and never has been a FIREWALL.

A flat screw drive and a flat chisel can both be used to remove screws or dig out wood.  They both work
well at what they are designed to do and not for which they are not designed to do.

---

From: Joe Maimon <[email-masked]>
Date: Wed, 30 Mar 2022 20:08:26 -0400

> well at what they are designed to do and not for which they are not designed to do.

There is no actual permanent solution for internal to external 
worm/tunneling protocols, except yanking the plug or equivalent security 
policy.

There is just blocking the method du-jour. When possible.

All this is irrelevant to my point, which seems to have sailed overhead 
that Jordi's little demonstration says nothing about NAT and security 
that it does not also say about a similarly configured IPv6 firewall and 
hence would be dishonest showboating.

Joe

---

From: Simon <[email-masked]>
Date: Thu, 31 Mar 2022 18:32:59 +0100

> On 30 Mar 2022, at 21:16, Joe Maimon <[email-masked]> wrote:

> That is backwards.

ONLY if you start from the premise that NAT is not in fundamental conflict with IP basics - namely that “packets can be routed from any end point to any other end point” (with the modern security proviso of “subject to administrative policies”.)
In any case, I’m used to configuring a firewall anyway. Most CE devices come with a stateful firewall installed and configured - most of them even with sensible defaults !

> NAT is an operational requirement. You have it because without it something does not work the way you want it to.

Not for IPv6. You are applying the “lets take IPv4 with all its faults and tack on some extra address bits” attitude. We should be taking the opportunity to fix the things that weren’t perfect/right with IPv4.
And for the record, in my last job we were lucky enough to have a whole /24 to play in - and we did, without NAT for the most part. And guess what, it worked very well thank you.
NAT is not strictly an operation requirement anyway, NAT is a sticking plaster on the festering sore of insufficient IP addresses. I would argue that NAT is the fundamental evil that is holding back adoption of a proper fix to the underlying problem - because it’s been “sold” as a solution by people who do not also mention that it’s broken and should be treated as a stopgap at most rather than the saviour of the internet it’s been hailed as.

Most of the discussions in this thread have come down to “the problems with NAT haven’t been a big enough pain point to trigger properly adopting IPv6” - mostly because many of the people making the decisions don’t actually get to see the problems and costs they are subjected to.
In a way there’s a parallel with the Y2k problem - I was one of many IT people doing work up front only to have both users and management ask “so what was the fuss about”. Of course, by fixing most problems invisibly up front, and the remaining ones as they cropped up, management never saw the underlying problem.

> On 30 Mar 2022, at 22:22, Joe Maimon <[email-masked]> wrote:
> 
> 
> 
> Simon wrote:

> In OSI speak thats a layering violation. An upper level protocol incorporates details and assumptions about lower layers as part of its operations.

Citation ?

> Unfortunately, TCP/IP and its application protocols are rife with them. Well more than one should expect were proper attention have been given to ensure that there was absolutely no equivalent proper way to do it.

So do you agree that HTTP is fundamentally broken then ? Either that, or it’s a protocol violation to run a service on anything but ports 80 and 443 ? Put another way, it’s a protocol violation to have a link to say my server:8443 ?

> Just because its common and convenient and usually works or can be made to work does not make it correct.

And of course, it’s usually done because it is the most sensible way to do it. Lets look at SIP for an example.

The device (lets assume a simple phone to keep things simple) needs to talk SIP in order to control sessions. But it makes complete sense to use a different protocol to transfer the audio streams (multiple) - and note what I said about the audio streams not necessarily going to the same place as the SIP user registration.
What you’ve said is that it should be “illegal” to allow my phone to exchange audio streams directly with someone else’s phone - OSI layer violation. Yet that is the most efficient way to do it (where it’s possible). The alternative is something like IAX where the application is effectively embedding a chunk of protocol stack - the ability to multiplex the packets of multiple streams inherent in IP (TCP or UDP) over one network - into the application. And in the world where all the traffic must be carried in one session, it means your voice traffic must pass through an “exchange” at both ends, adding delay and jitter as well as processing load to what would otherwise be a very lightweight application.

> In theory, the protocols are broken. If they hadnt taken the easy way out, we would not have to work around so many of them.

Again, citation. According to whom, other than the “NAT is beautiful” brigade are they broken ?

> RAM is cheap.

Not in many lightweight devices it isn’t.

Simon

---

From: Joe Maimon <[email-masked]>
Date: Thu, 31 Mar 2022 16:43:24 -0400

>>> Because if you don't have NAT, you are forced to properly configure a firewall.

Its backwards because the previous statement is only (partially) true 
when reversed.

When you have uni-directional NAT, such as NAPT44, you are forced to 
operate in a condition equivalent to having a firewall with a default 
deny-all(deny-most?) incoming policy.

When you have either IPv4 or IPv6 without that, you may or may not have 
a firewall, properly configured or otherwise.

> Not for IPv6.

Yes, precisely, which is why IPv6 is more likely to be less secure by 
default for its users. And for it to be at least as secure requires much 
greater efforts in multiple directions.

  You are applying the “lets take IPv4 with all its faults and tack on some extra address bits” attitude.

Dont put words in my mouth. I have no lack of them. My opinion on NAT 
with regard to IPv6 is that its a tool and if people want to use it, it 
should be standardized and available. How about less judgement on other 
peoples choices?

As far as IPv4 with more bits as a better approach to second system 
effect resulting in IPv6? The verdict on that has been in a long time 
ago. It would have been the smart play.

NAT is not an IPv4 fault. Its extremely wide spread adoption is due to 
IPv4 chief fault, only 32 bits.

> We should be taking the opportunity to fix the things that weren’t perfect/right with IPv4.
You tried, you failed.
>
> NAT is not strictly an operation requirement anyway,
For the vast majority of internet users today it is.
> NAT is a sticking plaster on the festering sore of insufficient IP addresses.

Or, NAT is a rather elegant method of multiplexing limited addressing as 
well as supplying other properties that may or may not have value to the 
user of the NAT.

Or did you like the sock proxy days?

That is negatively affects the  end2end dream? Insufficient addresses 
and the general insecurity of the net, vendor behavior, as well as the 
content concentration all did that together.

That it breaks protocols? They get fixed and life goes on. And protocols 
should not have been so brittle.

Side channel setup should have been standardized and used in a method 
that would have made it a fix-it-once problem for NAT's (and firewalls).

>> In OSI speak thats a layering violation. An upper level protocol incorporates details and assumptions about lower layers as part of its operations.

https://www.rfc-editor.org/rfc/rfc3724.html

Since the upper level protocol incorporates lower level properties into 
its functionality, it is now dependent on them.

The point I am trying to bring out is that it a valid exercise to 
re-examine the premise, namely that the protocol design was the correct 
and best way to go about it and the network should never have broken it.

I just think we would have been better off if doing that sort of thing 
required some sort of justification perhaps some amount of automatic 
recovery to an alternate, perhaps less efficient method. Some more 
robustness.

> So do you agree that HTTP is fundamentally broken then

A layer violation isnt automatically broken. Its just a red flag that 
maybe you should be rethinking that approach. Thats what design 
principals are for.

>   ? Either that, or it’s a protocol violation to run a service on anything but ports 80 and 443

This particular problem was part of what SRV records try to address.

> ? Put another way, it’s a protocol violation to have a link to say my server:8443 ?

HTTP does not require knowledge of specific port numbers to operate, so 
just because you have embedded it with URL's does not mean that HTTP is 
violating that design principle. Perhaps you are, especially if you dont 
actually control which port actually accepts that connection.

> And of course, it’s usually done because it is the most sensible way to do it. Lets look at SIP for an example.

This is a great example. SIP was so broken from the get go that it gave 
birth to the SBC. The thing it had going for it was that it was easier 
to fix than H323. And its not like NAT wasnt a thing when it was in 
infancy. Now imagine if there had been much more rigorous attention and 
design to opportunistically creating side channels while preserving the 
ability to transmit data within the channel.

Like SSH does.

Its not just NAT that endangers protocols that do these things, 
firewalls do as well. So lets just strip NAT from this aspect of the 
conversation and now we are just talking about proper firewall friendly 
protocol design. Or do you consider firewalls a fundamental evil as well?

Firewalls exist because of the existence of a fundamental evil present 
in any sufficiently large network. So I guess you would be correct with 
the label, just not where you stuck it.

> Not in many lightweight devices it isn’t.

You cant get a smartphone without gigs of ram today. Thats more memory 
than your honking server had back in the day. Yes it is cheap.

---

From: Nick Buraglio <[email-masked]>
Date: Thu, 31 Mar 2022 16:33:22 -0500

For 20+ years security vendors have conflated NAT and Firewall. That isn't
going to go away, frankly, and from the point of view of the security
engineer at an organization of a sufficient size, it doesn't matter if it
is technically correct or not. Obfuscating addressing is a very engrained
design model, largely because of this fact. I believe there is no a way
around that at least in the short term, probably also in the long term.
Understanding that what "enterprises" want is going to be driven by two
things: cost and risk. Address obfuscation is very, very, *very* (95%?)
present in enterprise architectures. Deviating from that is largely a
non-starter because it deviates from existing risk profiles and completely
changes the decades old architectures of application proxies and address
translation devices in strategic locations and like Joe M. has stated, the
fail closed model is by-and-large a requirement for many large
organizations.
If we want to understand what the enterprises want, we need to understand
their cost models and risk profiles.  Enterprises aren't going to fret much
about state tables, they'll buy bigger boxes. They aren't going to worry as
much about performance as, say, a service provider or a supercomputing
center. They care that their compliance requirements are met [see address
obfuscation, default deny, etc.], that their risk remains as low as
possible, and that their widget sells.
I hate to say it because I truly want the end to end connectivity, but I
believe that address translation with IPv6 is not going anywhere, and in
fact, will probably encourage deployment of v6 in the enterprise space.
It's a useful tool to get to where they want to be (again, see risk and
cost).
I think we need to rectify the fact that enterprises don't necessarily want
end to end connectivity for the above reasons, and I have seen significant
evidence pointing to that fact.

nb

On Thu, Mar 31, 2022 at 12:33 PM Simon <[email-masked]> wrote:

> ONLY if you start from the premise that NAT is not in fundamental conflict
> with IP basics - namely that “packets can be routed from any end point to
> any other end point” (with the modern security proviso of “subject to
> administrative policies”.)
> In any case, I’m used to configuring a firewall anyway. Most CE devices
> come with a stateful firewall installed and configured - most of them even
> with sensible defaults !
>
> Not for IPv6. You are applying the “lets take IPv4 with all its faults and
> tack on some extra address bits” attitude. We should be taking the
> opportunity to fix the things that weren’t perfect/right with IPv4.
> And for the record, in my last job we were lucky enough to have a whole
> /24 to play in - and we did, without NAT for the most part. And guess what,
> it worked very well thank you.
> NAT is not strictly an operation requirement anyway, NAT is a sticking
> plaster on the festering sore of insufficient IP addresses. I would argue
> that NAT is the fundamental evil that is holding back adoption of a proper
> fix to the underlying problem - because it’s been “sold” as a solution by
> people who do not also mention that it’s broken and should be treated as a
> stopgap at most rather than the saviour of the internet it’s been hailed as.
>
> Most of the discussions in this thread have come down to “the problems
> with NAT haven’t been a big enough pain point to trigger properly adopting
> IPv6” - mostly because many of the people making the decisions don’t
> actually get to see the problems and costs they are subjected to.
> In a way there’s a parallel with the Y2k problem - I was one of many IT
> people doing work up front only to have both users and management ask “so
> what was the fuss about”. Of course, by fixing most problems invisibly up
> front, and the remaining ones as they cropped up, management never saw the
> underlying problem.
>
>
> e.g. during session setup one end tells the other, please contact me at
> address X and port Y. That is quite common once you get past a basic “open
> connection, squirt some data, close session”. Examples that come
> immediately to mind :
>
> operations.
> > Unfortunately, TCP/IP and its application protocols are rife with them.
> Well more than one should expect were proper attention have been given to
> ensure that there was absolutely no equivalent proper way to do it.
>
> So do you agree that HTTP is fundamentally broken then ? Either that, or
> it’s a protocol violation to run a service on anything but ports 80 and 443
> to work does not make it correct.
>
> The device (lets assume a simple phone to keep things simple) needs to
> talk SIP in order to control sessions. But it makes complete sense to use a
> different protocol to transfer the audio streams (multiple) - and note what
> I said about the audio streams not necessarily going to the same place as
> the SIP user registration.
> What you’ve said is that it should be “illegal” to allow my phone to
> exchange audio streams directly with someone else’s phone - OSI layer
> violation. Yet that is the most efficient way to do it (where it’s
> possible). The alternative is something like IAX where the application is
> effectively embedding a chunk of protocol stack - the ability to multiplex
> the packets of multiple streams inherent in IP (TCP or UDP) over one
> network - into the application. And in the world where all the traffic must
> be carried in one session, it means your voice traffic must pass through an
> “exchange” at both ends, adding delay and jitter as well as processing load
> to what would otherwise be a very lightweight application.
>
> implementing the workaround code and support (e.g. adding the settings to
> the config pages) and users waste effort getting them set up right. All
> effort that could be better put to productive use rather than fighting
> broken networks.
> >

---

From: [email-masked]
Date: Thu, 31 Mar 2022 23:43:32 +0200

> In any case, I’m used to configuring a firewall anyway. Most CE devices come with a stateful firewall installed and configured - most of them even with sensible defaults !

My views on this has evolved over the last couple of decades.
I have come to believe that freedom to rewrite the locator at various network edges is an important property of IP.
NAT is a somewhat unfortunate implementation of a locator / identifier split. But we have tried many others 8+8, LISP, ILNP...
The need for protecting your network against global address changes in smaller networks, or providing a service abstraction (VIP) in DCs. Or making your network appear like a host for permissionless extensions of the network are valid use cases, regardless of version of the IP protocol.

O.

---

From: Fred Baker <[email-masked]>
Date: Thu, 31 Mar 2022 17:41:22 -0700

> On Mar 29, 2022, at 9:23 PM, Brian E Carpenter <[email-masked]> wrote:
> 

I would expect a very large percentage of it is. I can only speak of my own usage, but in my case it's not unusual to look up a potential plane ticket (or other product/service) on several airlines on several sites a long time in advance of actually making a purchase. Every such exploratory access will be a case in which I decided to "not buy" and probably is detected as a session failure by the site(s) I'm visiting.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 1 Apr 2022 14:12:35 +1300

> I would expect a very large percentage of it is. I can only speak of my own usage, but in my case it's not unusual to look up a potential plane ticket (or other product/service) on several airlines…

Yes, from the server's viewpoint, a timeout caused by NAT state loss is probably impossible to distinguish from a timeout caused by the user getting bored or switching to a different airline.

    Brian