On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG <
nanog@nanog.org> wrote:
Use SLAAC, allocate prefixes from both providers. If you are using multiple routers, set the priority of the preferred router to high in the RAs. If you’re using one router, set the preferred prefix as desired in the RAs.
Owen
I agree this works, but I assume that we would not consider this a consumer level solution (requires an administrator to make it work). It also assumes the local network policy allows for auto-addressing vs. requirement for DHCP.
It shouldn’t require an administrator if there’s just one router. If there are two routers, I’d say we’re beyond the average consumer.
In the consumer world (Where a consumer has no idea who we are, what IP is and the Internet is a wireless thing they attach to).
I am only considering one router (consumer level stuff). Here is my example:
- Mr/Ms/Ze. Smith is a consumer (lawyer) wants to work from home and buy a local cable service and/or DSL service, and/or xPON service
- Both providers have IPv6 (competing in the market so don't cooperate on how to address, manage customer homes)
- Mr/Ms/Ze Smith has no idea what IPv4 is, what IPv6 is or anything anything else technical (typical consumer); They only knows how to walk into a store and buy a random thing off the shelf and ask for "WiFi".
- Both providers provide IPv6 and delegate a prefix to the router (let's pretend the retail staff knew enough to sell this person a consumer box with 2x WAN interfaces)
- Lets also assume the cable boxes have a consumer actionable way to force R1483 mode, and assume the DSL device can do the same (I know many providers that don't allow this type of configuration)
- So this dual WAN (retail) device now has one Public IPv4 address per WAN interface (assuming one or both of the services was not disallowing bridging mode, in which case its a Private address on one or both of the WAN interfaces)
- this dual wan device also gets a PD from both upstream providers which delegates to the CPE
I will ignore the dual router case as that normally looks very ugly in networks as customers typically don't hook that up correctly (normally hook one box in behind the first, not in parallel). Do we think this use case just works today? Can we say we are confident we know how this all pans out in real production? e.g. CPE only uses one PD? uses both? does all the right things to support SLAAC downstream?
I hate to say it, but for the IPv4 case, as ugly as NAT is, I know what happens and normally the consumer has no clue what's going on and the router just deals with it. For the IPv6 side, I am not yet confident this is all just working yet. I would like to be wrong. I can say - in my consumer mode in the US - this example above is not working by default. (I won't out the providers of course). I want the answer to be different, but there is still more work to do (especially since dual provider has become much more common due to work from home).
regards,
Victor K
I have had IPv6 in my home for a long time now using multiple providers, but it definitely works with high touch admin. I don't see this as a barrier to deploy IPv6 though (don't read that into my response). But IPv6 still has a few corner cases that require some TLC.
It’s not high touch in my environment, but my environment goes way beyond consumer and involves ARIN assigned GUA and BGP.
Not every home is the same.
Owen
regards,
Victor K
Oh well.. Then how you gonna solve the el-cheapo SOHO multihoming?
Im currently dual homed, having 2 uplinks, RFC1918 LAN, doing policy
routing and NATing however I want..
why of COURSE you do source address selection!
so simple!
---------- Original message ----------
From: Mark Andrews <marka@isc.org>
To: borg@uu3.net
Cc: nanog@nanog.org
Subject: Re: IPv6 woes - RFC
Date: Wed, 29 Sep 2021 00:28:40 +1000
> On 28 Sep 2021, at 19:19, borg@uu3.net wrote:
>
> Heh, NAT is not that evil after all. Do you expect that all the home
> people will get routable public IPs for all they toys inside house?
Yes! Remember routable does not mean that it is reachable from outside.
> And if they change ISP they will get new range?
Yes! What do you think DHCPv6 Prefix Delegation is all about? It
has only been specified for 18 years now. The IPv6 address ranges ISP
get for RIRs are based on handing out multiple /64 to every customer.
> Doesnt sounds nice to me.. But I guess I its just me
It sounds like you need to do some reading about IPv6, then actually
use it. 100s of millions of home customers are get routable IPv6 prefixes
today around the world. It's not scary. Things don˙˙t blow up.
> Yeah I am aware of putting additional aliases on loopback.
>
> No futher comment about ND and DHCP.
>
> Well, at a time when TCP/IP was invented, 32bit address space looked
> pretty much big... I dont blame them than they didnt predicted future..
> Unfortunately, cant say the same about IPv6 R&D taskforce ;)
>
> Hah, multicast... Ill skip it.
>
> Followed change to support CIDR, Internet was still small and considered
> R&D field...
>
> Okey, I think its no need to futher pollute NANOG list with this.
> I said at the begining that this is just my subjective opinion.
> This will not help IPv6 case at all.
>
> At least from my (2) standpoint it would be really cool that IPv6
> would be finally addopted.
>
> I just wanted to share my toughts about why im not big fan of IPv6.
> I also wanted to hear other opinions what they dislike about it, no
> list of how cool IPv6 is and how everyone should use it right away.
>
>
> ---------- Original message ----------
>
> From: Owen DeLong <owen@delong.com>
> To: borg@uu3.net
> Cc: nanog@nanog.org
> Subject: Re: IPv6 woes - RFC
> Date: Sat, 25 Sep 2021 12:01:22 -0700
>
>
>
>> On Sep 25, 2021, at 01:57 , borg@uu3.net wrote:
>>
>> Well, I think we should not compare IPX to IPv4 because those protocols
>> were made to handle completly different networks?
>>
>> Yeah, IPv6 is new, but its more like revolution instead of evolution.
>>
>> Well, Industry seems to addapt things quickly when they are good enough.
>> Better things replace worse. Of course its not always the case, sometimes
>> things are being forced here.. And thats how I feel about IPv6..
>
> Sometimes worse things replace better. NAT, for example was definitely not
> an improvement to IPv4. It was a necessary evil intended to be a temporary
> fix.
>
>>
>> IPv4 Lookback is 127.0.0.1/8
>> You can use bind IPs within range by applications. Handy
>> In IPv6 its not the case.
>
> You are free to assign any additional IPv6 addresses you like to the loopback
> interface and then bind them to applications. Personally, I haven˙˙t found a
> particularly good use for this, but it is possible.
>
> It does mean that instead of wasting 1/256th of the entire address space
> in every context on loopbacks, you have to assign what you need there,
> but you can easily assign a /64 prefix to a loopback interface and have
> applications bind within range.
>
>> IPv6 ND brings new problems that has been (painfully?) fixed in IPv4.
>> Tables overflows, attacks and DDoS.. Why to repeat history again?
>
> Table overflows weren˙˙t fixed in IPv4 and have nothing to do with ND vs.
> ARP. Table overflows are (not really an issue in my experience) the
> result of a larger address space than the memory available for the L2
> forwarding table on switches or the ND table on hosts. This isn˙˙t due
> to a difference in ND vs. ARP. It is due to the fact that there are no
> 64-bit networks in IPv4, but they are commonplace in IPv6.
>
> Mostly this has been solved in software by managing table discards more
> effectively.
>
>> IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some
>> issues. If this is not the case, im sorry. Its been a while when I last time
>> played with IPv6...
>
> I am using IPv6 and I˙˙m using IPv6 DHCP. I haven˙˙t encountered any significant
> problems with it other than some minor inconveniences introduced by the ability
> to have different DUID types and vendors doing semi-obnoxious things along that
> line.
>
>> IPv6 interop: yeah, I agree here.. But people involved with IPv6 should
>> think about some external IPv4 interop.. Internet was exploding at 1997..
>> Maybe they had hope that everyone upgrade like in CIDR case. And maybe it
>> could happen if IPv6 wasnt so alien ;)
>
> It was thought about˙˙ It was considered. It was long pondered. Problem was,
> nobody could come up with a way to overcome the fact that you can˙˙t put
> 128 bits of data in a 32 bit field without loss.
>
> IPv6 really isn˙˙t so alien, so I don˙˙t buy that argument. The software changes
> necessary to implement IPv6 were significantly bigger than CIDR and IPv6
> affected applications, not just network. There was no way around these
> two facts. The IPv6 network stack did get adopted and implemented nearly
> as fast as CIDR and virtually every OS, Switch, Router has had IPv6 support
> for quite some time now at the network stack level. It is applications and
> content providers that are lagging and they never did anything for CIDR.
>
>> As for IPv4 vs IPv6 complexity, again, why repeat history.
>
> What complexity?
>
>> Biggest IPv4
>> mistake was IPv4 being classfull. It was fixed by bringing CIDR into game.
>
> No, biggest IPv4 mistake was 32-bit addresses. A larger address would have been
> inconvenient in hardware at the time, but it would have made IPv4 much more
> scalable and would have allowed it to last significantly longer.
>
>> (Another big mistake was class E reservation...)
>
> Not really. It was a decision that made sense at the time. Class D reservation
> made sense originally too. Without it, we wouldn˙˙t have had addresses available
> to experiment with or develop multicast.
>
> There was no way to know at the time that decision was made that IPv4 would run
> out of addresses before it would find some new thing to experiment with.
>
>> Internet was tiny at that time so everyone followed.
>
> Followed what, exactly?
>
>> Image something like this today? Same about IPv6.. it brings
>> forced network::endpoint probably due to IoT, sacrificing flexibility.
>
> I can˙˙t parse this into a meaningful comment. Can you clarify please?
> What is ˙˙forced network::endpoint˙˙ supposed to mean and what does it
> have to do with IoT? What flexibility has been sacrificed?
>
>> Again, I dont want to really defend my standpoint here. Its too late for
>> that. I kinda regret now dropping into discussion...
>
> OK, so you want to make random comments which are not even necessarily
> true and then walk away from the discussion? I have trouble understanding
> that perspective.
>
> I˙˙m not trying to bash your position or you. I˙˙m trying to understand your
> objections, figure out which ones are legitimate criticism of IPv6, which
> ones are legitimate criticism, but not actually IPv6, and which ones
> are simply factually incorrect. For the last category, I presume that comes
> from your lack of actual IPv6 experience or some other form of ignorance
> and I˙˙d like to attempt useful education to address those.
>
> Owen
>
>>
>>
>> ---------- Original message ----------
>>
>> From: Grant Taylor via NANOG <nanog@nanog.org>
>> To: nanog@nanog.org
>> Subject: Re: IPv6 woes - RFC
>> Date: Fri, 24 Sep 2021 14:26:27 -0600
>>
>> On 9/24/21 11:53 AM, borg@uu3.net wrote:
>>> Well, I see IPv6 as double failure really.
>>
>> I still feel like you are combining / conflating two distinct issues into one
>> generalization.
>>
>>> First, IPv6 itself is too different from IPv4.
>>
>> Is it? Is it really? Is the delta between IPv4 and IPv6 greater than the delta
>> between IPv4 and IPX?
>>
>> If anything, I think the delta between IPv4 and IPv6 is too small. Small enough
>> that both IPv4 and IPv6 get treated as one protocol and thus a lot of friction
>> between the multiple personalities therein. I also think that the grouping of
>> IPv4 and IPv6 as one protocol is part of the downfall.
>>
>> More over if you think of IPv4 and IPv6 dual stack as analogous to the
>> multi-protocol networks of the '90s, and treat them as disparate protocols that
>> serve similar purposes in (completely) different ways, a lot of the friction
>> seems to make sense and as such becomes less friction through understanding and
>> having reasonable expectations for the disparate protocols.
>>
>>> What Internet wanted is IPv4+ (aka IPv4 with bigger address space, likely
>>> 64bit). Of course we could not extend IPv4, so having new protocol is fine.
>>
>> I don't think you truly mean that having a new protocol is fine. Because if you
>> did, I think you would treat IPv6 as a completely different protocol from IPv4.
>> E.g. AppleTalk vs DECnet. After all, we effectively do have a new protocol;
>> IPv6.
>>
>> IPv6 is as similar to IPv4 as Windows 2000 is similar to Windows 98. Or
>> "different" in place of "similar".
>>
>>> It should just fix problem (do we have other problems I am not aware of with
>>> IPv4?) of address space and thats it. Im happy with IPv4, after 30+ years of
>>> usage we pretty much fixed all problems we had.
>>
>> I disagree.
>>
>>> The second failure is adoption. Even if my IPv6 hate is not rational, adoption
>>> of IPv6 is crap. If adoption would be much better, more IPv4 could be used for
>>> legacy networks ;) So stuborn guys like me could be happy too ;)
>>
>> I blame the industry, not the IPv6 protocol, for the lackluster adoption of
>> IPv6.
>>
>>> As for details, that list is just my dream IPv6 protocol ;)
>>>
>>> But lets talk about details:
>>> - Loopback on IPv6 is ::1/128
>>> I have setups where I need more addresses there that are local only.
>>> Yeah I know, we can put extra aliases on interfaces etc.. but its extra
>>> work and not w/o problems
>>
>> How does IPv6 differ from IPv4 in this context?
>>
>>> - IPv6 Link Local is forced.
>>> I mean, its always on interface, nevermind you assign static IP.
>>> LL is still there and gets in the way (OSPFv3... hell yeah)
>>
>> I agree that IPv6 addresses seem to accumulate on interfaces like IoT devices do
>> on a network. But I don't see a technical problem with this in and of itself.
>> -- I can't speak to OSPFv3 issues.
>>
>>> - ULA space, well.. its like RFC1918 but there are some issues with it
>>> (or at least was? maybe its fixed) like source IP selection on with
>>> multiple addresses.
>>
>> I consider this to be implementation issues and not a problem with the protocol
>> itself.
>>
>>> - Neighbor Discovery protocol... quite a bit problems it created.
>>
>> Please elaborate.
>>
>>> What was wrong w/ good old ARP? I tought we fixed all those problems
>>> already like ARP poisoning via port security.. etc
>>
>> The apparent need to ""fix / address / respond to a protocol problem at a lower
>> layer seems like a problem to me.
>>
>>> - NAT is there in IPv6 so no futher comments
>>> - DHCP start to get working on IPv6.. but it still pain sometimes
>>
>> What problems do you have with DHCP for IPv6? I've been using it for the better
>> part of a decade without any known problems. What pain are you experiencing?
>>
>>> And biggest problem, interop w/ IPv4 was completly failure.
>>
>> I agree that the interoperability between IPv4 and IPv6 is the tall pole in the
>> tent. But I also believe that's to be expected when trying to interoperate
>> disparate protocols.
>>
>>> From ground zero, I would expect that disparate protocols can't interoperate
>> without external support, some of which requires explicit configuration.
>>
>>> Currently we have best Internet to migrate to new protocol. Why?
>>
>> The primary motivation -- as I understand it -- is the lack of unique IP
>> addresses.
>>
>>> Because how internet become centralized. Eyeball networks just want to reach
>>> content. E2E communication is not that much needed. We have games and
>>> enhusiast, but those can pay extra for public IPv4. Or get VPN/VPS.
>>
>> Now you are talking about two classes of Internet connectivity:
>>
>> 1) First class participation where an endpoint /is/ /on/ the Internet with a
>> globally routed IP.
>> 2) Second class participation where an endpoint /has/ /access/ /to/ the
>> Internet via a non-globally routed IP.
>>
>> There may be some merit to multiple classes of Internet connectivity. But I
>> think it should be dealt with openly and above board as such.
>>
>>> And end comment. I do NOT want to start some kind of flame war here. Yeah I
>>> know, Im biased toward IPv4.
>>
>> I don't view honest and good spirited discussion of facts and understanding to
>> be a flame war. In fact, I view such discussions as a good thing.
>>
>>> If something new popups, I want it better than previous thingie (a lot) and
>>> easier or at least same level of complications, but IPv6 just solves one thing
>>> and brings a lot of complexity.
>> Please elaborate on the complexity that IPv6 brings that IPv4 didn't also bring
>> with it in the '90s?
>>
>> Would the things that you are referring to as IPv6 complexities have been any
>> different if we had started with IPv6 instead of IPv4 in the '80s & '90s?
>>
>> In some ways it seems to me that you are alluding to the legacy code / equipment
>> / understanding / configuration / what have you. This is something that many
>> have been dealing with for quite a while. The mainframe's ability to run code
>> from near half a century ago comes to mind.
>>
>>> The fact is, IPv6 failed.
>>
>> I concede that IPv6 has faltered. But I don't believe it's failed. I don't
>> think it's fair to claim that it has.
>>
>>> There are probably multiple reasons for it. Do we ever move to IPv6? I dont
>>> know.. Do I care for now? Nope, IPv4 works for me for now.
>>
>> You are entitled to your own opinion as much as I'm entitled to mine. But the
>> key thing to keep in mind is that it's /your/ opinion. The operative word being
>> "your" as in "you". Your views / opinions / experiences are /yours/. What's
>> more important is that other people's views / opinions / experiences may be
>> different.
>>
>>
>>
>> --
>> Grant. . . .
>> unix || die
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org