Re: [v6ops] Fwd: New Version Notification for draft-linkova-v6ops-ipmaclimi-00.txt

[Chongfeng Xie <[e-mail]>]

 
 
Hi Jen,
Based on your introduction,nI think this problem is mainly about how the host obtains multiple IPv6 addresses from the next-hop router. I don't know whether this issue focuses on multiple scenarios, such as mobile more networks or clouds, let me take wired-broadband as an example, due to the address structure and size of IPv6 space, operators currently assign address prefixes to customers, such as a /64 or a larger address prefix, such as a /56 via DHCP-PD, instead of single addresses. After getting the address prefix from the network side, the customer's router (usually a single CE device or multiple CE devices) will further allocate it. At this time, the source address of IPv6 packets sent by the customer should be within the range of the address prefix assigned by operator, otherwise it is an illegal address.
The next-hop router mentioned here may be customized by the operator, or it may not be customized by the operator but purchased from 3rd party by the customer. In the latter case, the network administrator maybe user him or herself who is responsible for these related management configurations. In addition, if the software and hardware resources of CE devices purchased from 3rd party does not meet the requirements of multiple addresses, as Pascal mentioned, an IPv6 address comes at a cost , this may affect the overall end-to-end performance of the network or even affect the user experience. Most likely, operators will be the target to be blamed, although it's not its responsibility. Furthermore, if multiple addresses are generated based on the multi-homing, multiple operator addresses will be involved. This may become more complex than whether how to control multiple address allocation. So this is not only about the limitation of multiple address allocations, but also about how to use multiple addresses reasonably to ensure a normal communication.

Best regards
Chongfeng


[e-mail]
 
From: Jen Linkova
Date: 2022-11-08 19:42
To: Chongfeng Xie
CC: list
Subject: Re: [v6ops] Fwd: New Version Notification for draft-linkova-v6ops-ipmaclimi-00.txt
Hi Chongfeng,
 
You are absolutely right! The -01 will contain more text about that
indeed, I just wanted to submit -00 ASAP to start the discussion.
Meantime I can just tell that ChromeOS, for example, is actively using
various virtualization and container techniques for running guest OSs
like Android, Linux distros, Windows VMs, as well as for security
(namespacing). So right now to function properly, a ChromeOS device
would require around 7-9 addresses *in a single prefix network*. Now
think about what happens if you are doing graceful renumbering or have
a multi-prefix environment...
 
On Tue, Nov 8, 2022 at 6:32 PM Chongfeng Xie <[e-mail]> wrote:
>
> Jen,
> I don't see any scenarios where each host may have too many IPv6 addresses, but I am interested in this.  Would it be more convincing if it could be mentioned in the draft?
> Best regards
> Chongfeng
>
> ________________________________
> [e-mail]
>
>
> From: Pascal Thubert \(pthubert\)
> Date: 2022-11-08 15:08
> To: Jen Linkova; V6 Ops List
> Subject: Re: [v6ops] Fwd: New Version Notification for draft-linkova-v6ops-ipmaclimi-00.txt
> Hello Jen
>
> I read the draft. I agree there's an issue. I believe the draft makes the wrong assumption, and therefore cannot solve that issue.
>
> The wrong assumption is that the router vendors can impose anything. The limitation does not come from the vendors. It comes from the network operators. Why so? Because in an enterprise network, an IPv6 address comes at a cost. As the draft points out, there's ND proxy state. There's also some amount of broadcast, meaning energy, bandwidth, and spectrum, for which the network must be provisioned. There's infrastructure backend like EVPN for which routing capabilities must be assigned. There's security screening to protect the address ownership and identify misuses. All that is both necessary and expensive, per address.
>
> In the real world the network admin lives on a budget. Meaning that the amount of traffic and the amount of addresses are bounded. That's a fact, and it's not the vendors imposing it.
>
> As presented, this draft is exactly as doomed as other hopeful thinking like core routers will process HbH EHs in the past. Compared to PMTUD or EH processing, the situation is a lot easier here, though. Because the issue is not about all the routers along the path, it's just between the host and its router. Sadly, with classical ND, the host lives on the illusion that it can get anything, and never needs to tell when an address is created, when the address is deprecated, or when the address moves.
>
> See it as an old couple where one side is aware of the budget and the other, who is not, will ask anything. It can never last. An arbitrary number like 20 that cannot be guaranteed is a meaningless illusion, which only obfuscates the problem a little more as oppose to solving it.
>
> The problem, as I tried to explain yesterday at 6MAN, is this: in the current state of affairs, the network misses some state (silent hosts, causing the ugly BUM that users do hate quite a lot), and maintains stale state for addresses that the host does not use anymore or that have moved. Which means wasting energy and resources at a time when we should really be sensitive to power and sustainability. And when an administrative limit of number of addresses is reached, there is no way in classical ND for the network administrator to tell the host that the budget is spent. So the host thinks it can use the address when really it cannot.
>
> Bottom line: the routers do not have a deterministic knowledge of which address is where, and everything that we build on top (ND proxy, EVPN) is built on sand. And the hosts do not have a deterministic knowledge that they own an address and will get the traffic for it. How could people trust and deploy IPv6 in these conditions? We agree on one thing: the failures that we observe today are ugly. They are ugly because they are silent, which is a clear sign that we collectively failed, and our users pay for our mistakes.
>
> Our old couple needs to have a serious discussion. We need a protocol. Or more precisely we need to implement the protocol that we already have, because that problem was already observed, solved, and the solution deployed by millions, see RFC 8929.
>
> All the best,
>
> Pascal
>
> > -----Original Message-----
> > From: v6ops <[e-mail]> On Behalf Of Jen Linkova
> > Sent: mardi 8 novembre 2022 2:25
> > To: V6 Ops List <[e-mail]>
> > Subject: [v6ops] Fwd: New Version Notification for draft-linkova-v6ops-
> > ipmaclimi-00.txt
> >
> > Hello,
> >
> > As I've come across some rather nasty failure scenarios, affecting both
> > IPv6-only and dual-stack deployments, I think it might be useful to re-
> > emphasize RFC7934 and provide some recommendations to vendors.
> >
> > This is a rather raw -00, the text is very brief and unpolished, it will
> > be definitely expanded and improved, should the group agree that this is a
> > problem worth solving.
> >
> > Feedback/comments are appreciated indeed!
> > Thanks!
> >
> > ---------- Forwarded message ---------
> > From: <[e-mail]>
> > Date: Tue, Nov 8, 2022 at 12:15 PM
> > Subject: New Version Notification for draft-linkova-v6ops-ipmaclimi-00.txt
> > To: Jen Linkova <[e-mail]>
> >
> >
> >
> > A new version of I-D, draft-linkova-v6ops-ipmaclimi-00.txt
> > has been successfully submitted by Jen Linkova and posted to the IETF
> > repository.
> >
> > Name:           draft-linkova-v6ops-ipmaclimi
> > Revision:       00
> > Title:          Minimizing Damage of Limiting Number of IPv6 Addresses per
> > Host
> > Document date:  2022-11-07
> > Group:          Individual Submission
> > Pages:          5
> > URL:
> > https://www.ietf.org/archive/id/draft-linkova-v6ops-ipmaclimi-00.txt
> > Status:         https://datatracker.ietf.org/doc/draft-linkova-v6ops-
> > ipmaclimi/
> > Html:
> > https://www.ietf.org/archive/id/draft-linkova-v6ops-ipmaclimi-00.html
> > Htmlized:
> > https://datatracker.ietf.org/doc/html/draft-linkova-v6ops-ipmaclimi
> >
> >
> > Abstract:
> >    This document provides recommendations to network infrastructure
> >    vendors on how to deal with multiple IPv6 addresses per host.
> >
> >
> >
> >
> > The IETF Secretariat
> >
> >
> >
> >
> > --
> > SY, Jen Linkova aka Furry
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
 
 
 
-- 
SY, Jen Linkova aka Furry