Re: [v6ops] I-D Action: draft-fbnvv-v6ops-site-multihoming-00.txt

[Vasilenko Eduard <[e-mail]>]

Hi Brian,
Thanks for many very useful comments - you would see a lot of changes in the new version.

>"5.1. PI-based
>...
>Advantages:"
> Isn't the #1 advantage: It works today! ?

Nick was trying to implement MH in his home and found that only PI and NAT66 work.
It is the more or less typical situation now for the real CPEs.
If we would mention for PI "it works today",
Then should we mention for NAT66 "it works today" too?

IMHO: all 4 solutions "works today" in particular situations (with particular restrictions).
For example, for PI one needs proper address space acquired.

PS: we did mention in the conclusion that PI is the best technical choice.
It looks like what you were trying to say.

Eduard
-----Original Message-----
From: Brian E Carpenter [mailto:[e-mail]] 
Sent: Saturday, March 4, 2023 6:09 AM
To: IPv6 Operations <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D Action: draft-fbnvv-v6ops-site-multihoming-00.txt

Hi,

Some comments (not really a full review):

Firstly, thanks for starting this work, it is badly needed.

Second, a bit off topic, but it was recently rediscovered where I live (New Zealand) that any amount of MHMP won't help you if your region is supplied by a single fibre trunk shared by all providers, and a landslide removes that trunk. It might be worth reminding readers of that. We really need MHMPMD (MD = multiple ducts).

Thanks for citing RFC4864 as relevant history, but I think you are missing quite a lot by not citing the multi6 work
(5 RFCs at https://datatracker.ietf.org/wg/multi6/documents/).
And of course there is the sad story of the perfect solution that did not work (https://datatracker.ietf.org/wg/shim6/documents/).
There are lessons to be learned in all those documents, I suspect.
At least, readers should understand that this is an old problem and why we have failed to solve it several times.

Since you also mention renumbering, we have failed there too:
https://datatracker.ietf.org/wg/6renum/documents/ .
Also part of the history.

Where you state "There are 4 potential possible solutions..."
I suggest confronting that with the analysis in RFC4177.

One of the four solutions reads:

"- Dynamic PA addresses distribution and withdrawal from carriers"

I think that is really hiding a more traditional solution, something like:

- Static PA addresses from multiple carriers, chosen dynamically
   by hosts.

That is actually the "classical" model since the early days of of IPv6. It's the model assumed by SHIM6, which worked by choosing a working combination of PA addresses at each end.
Unfortunately, it doesn't work too well without something like SHIM6 (see the recent discussion "Deprecating failed prefixes in the host"). But I'll stick to my guns: whatever we do in the routing system, hosts SHOULD deprecate source prefixes when they are detected to fail. It's possible, even with RFC6724 in place, and it's the same sort of self-defence as Happy Eyeballs.

Dynamic prefix assignment and withdrawal is a *new* model.
Whether it can be made to work is an open question.

"The initial discussion on carrier resiliency occurred in the [Shim6] working group, where it was proposed to separate the location and identity properties of addresses. [Shim6] did not gain market acceptance."

In fact, that discussion started in the MULTI6 WG, which led to
SHIM6 as the preferred approach. If you want to set the historical context, it wasn't really a question of "market acceptance". What actually happened was surprisingly strong opposition from carriers who (correctly) perceived SHIM6 as removing some of their ability to steer traffic, and giving their customers the ability to pick a path that suited them, the customers, best. And they (the carriers) had the ability to prevent SHIM6 deployment by filtering on the SHIM6 extension header. ("Deprecating failed prefixes in the host" is essentially single- ended SHIM6, because the probe packets don't look special.)

I'm ranting about this because whatever solution we propose must satisfy the needs of end hosts at least as well as it satisfies the needs of enterprise network operators and carriers. And that aspect isn't clear to me in the list that starts "4. Solution requirements".
(I'd personally prefer a solution that requires no new action whatever by the carriers.)

One of the requirements:

"4. Sub-second convergence for the prefix deprication..."

comes out of nowhere. Won't this vary widely? In a small office network, why not 5 seconds or 30 seconds? In a stock trading data centre, wouldn't they want sub-millisecond convergence?

Maybe a better goal would be: Convergence on the same time scale as normal internal routing convergence.

"5. Support for sites with complex topologies, including multiple internal on-site hops requiring many routers and links."

Also cover the case of redundant topologies (>1 router per subnet).

"Privacy is furthermore assumed to be protected by [Temporary addressing] and is also kept outside of the carrier resiliency design consideration."

I think that needs rewording. Some enterprises forbid temporary addresses, so the assumption is sometimes false. I think it would be safer to say that address-based privacy considerations are not affected by carrier resiliency in itself. (They might be affected by the choice to use or not use NAT66 or NPTv6, but that is a separate discussion.)

"5.1. PI-based
...
Advantages:"

Isn't the #1 advantage: It works today! ?

"Disadvantages:
...
- Bloats the Internet routing table."

How about

- Bloats the Internet routing table with a potential 10 million new routes. ?

I don't think we should make this solution sound satisfactory.

"5.2. PA-based solution
...
It is mandatory to implement requirement L-13 of [HNCP] section 11 to deprecate delegated prefixes..."

That reads as if you are proposing HNCP for everyone, which I am sure is not your intention. Can you rephrase it to sound like a property of the solution?

"Potentially, the application on the host may use bind() to choose the source address..."

Yes, but most applications don't do that, they start with getaddrinfo().
So what is the value of this discussion of bind()?

"It may be valuable to implement [Provisioning domains]..."

What is the probability of that happening?

"Disadvantages:
...
    - Carriers may frequently change the prefix (flash renumbering), and
      this could disrupt communication"

Why is that new? Many IPv6 carriers do that for SOHO users today. I think they don't do it for larger enterprises, though.

"5.3. ULA with NPT
...
    However, [ULA] has
    notable limits concerning the number of sites that one prefix may
    span, and well documented usability limitations when considering
    address selection details across large, diverse network
    environments."

I'm not sure these limits are "well documented". If they are, please give a reference.

"Network Prefix translation [NPT]..."

Its "official" abbreviation is NPTv6.

"5.4. ULA with NAT66
...
Advantages:
...
- NAT may be a normative requirement in itself (this is highly
      questionable, but nonetheless brought forward in many
      discussions)"

Note that PCI-DSS (version 4, March 2022) does not require NAT, although it is mentioned as a solution for IPv4. See https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0.pdf

" 6. Conclusion"

I think in general this section is premature, until the earlier sections have been widely reviewed and updated. So mainly I will not comment, but:

"For sites having a complex topology (many links and routers), a PA-
    based solution is not an option yet,..."

Agreed, but:

"... because it would need automatic
    PA address distribution over the site and neither [HNCP] nor DHCP-PD
    have gained market acceptance for this task."

That is needed for flash renumbering, but NOT for a static multi-PA solution. There, the requirement is much simpler: prefix up/down status distribution over the site. That's close to a trivial problem to solve, if we decide to solve it. (For example, it would be easy to define a GRASP [RFC8990] method for it, and I'm sure there are ten other solutions waiting.)

Regards
    Brian Carpenter

On 04-Mar-23 03:59, [e-mail] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>          Title           : IPv6 Site connection to many Carriers
>          Authors         : Nick Buraglio
>                            Klaus Frank
>                            Paolo Nero
>                            Paolo Volpato
>                            Eduard Vasilenko
>    Filename        : draft-fbnvv-v6ops-site-multihoming-00.txt
>    Pages           : 32
>    Date            : 2023-03-03
> 
> Abstract:
>     Carrier resilience is a typical business requirement. IPv4
>     deployments have traditionally solved this challenge through private
>     internal site addressing in combination with separate NAT engines
>     attached to multiple redundant carriers. IPv6 brings support for
>     true end-to-end connectivity on the Internet, and hence NAT is the
>     least desirable option in such deployments. Native IPv6 solutions
>     for carrier resiliency, however, have drawbacks. This document
>     discusses all currently-available options to organize carrier
>     resiliency for a site, their strengths and weaknesses, and provides
>     a history of past IETF efforts approaching the issue. The views
>     presented here are the summary of discussions on the v6ops mailing
>     list and are not just the personal opinion of the authors.
> 
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-fbnvv-v6ops-site-multihoming/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-fbnvv-v6ops-site-multihomi
> ng-00
> 
> 
> Internet-Drafts are also available by rsync at 
> rsync.ietf.org::internet-drafts
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt