Only because (some of) the IPv6 designers espoused similarly grandiose ideas was android in a position to implement its policy while being in compliance with the IPv6 specs. Really it is no secret that some of the IPv6 crowd was principally oposes to DHCP and tried to fold the things they considered useful into IPv6. My point is not whether they functionally succeded or not, but that it was that mindset that prepared the ground for what android did later.
Rather hamfisted.... but again my point is aided by IPv6' design.
Such a choice is not required, as ISPs already give out anything down to /64s to endusers... I really doubt that ISPs have sufficient motivation to touch the interface identifier as for all their purposes the prefix used for routing is sufficiently informative.
Again IPv6 solves at least one big show-stopper problem in IPv4 and if only for that reason is (rightly) going to stay, however that does not force me to retroactively love all decisions that were made. Regarding DHCP, my use-case is only mildly complicated by the issues (would just be convenient to be able to organise making services available from one place, instead of two router/firewall and endhost/permanent addresses), my colaint is about the mindset that resulted in IPv6 not accepting existing use-cases and predictably failing to come up with equivalent alternatives.
Reliance Jio has both ipv6 and ipv4. I am not sure about Airtel and Vi but Jio alone has 400 million subscribers in India. if I want ipv6 then either I buy jio or use something like apple private relay which I think gives me a ipv6 to 4 tunnel if I am on an ipv4 connection. I have tried a few broadbands in India and none of them have ipv6 for home users.
Which is an option that is sort of supported in IPv6... I understand your rationale for infrastructure, my argument is more that for shepherding end-devices something that allows central control/configuration is somewhat desirable. As I said for sharing stuff over IPv4 I can do this nicely in the router, for IPv6 I need to configure both the router and the end host... (I have no issue if end-hosts can be configured to ignore the router's address assignments, just by default I would appreciate if I could fix these addresses, if only to be able to easier monitor what remote addresses my android devices want to "talk" to (which already works well over IPv4)).
As another poster noted thru practical experience:
As I recall, RFCs stipulate that one assign a static IPv6 address per service (recall some of the "fancy" IPs that resolve Meta'$ frontend server hostnames - e.g. xxxx:face:b008, etc.). So this discussion is out-of-parameter anyways.
I personally use a tunnel service for static addressing; as my ISP changes subnets (prefixes) often
Otherwise, DDNSv6 on the client would suffice
This is on the OpenWrt. But yes, this can be enabled on clients. I don't understand why one should for an inbound service, though.
EDIT: I should add - this is why the first premier IPv6 ISP in the US (and most of the world) - Hurricane Electric offered DNS and DDNS along with thier IPv6 tunnel services (and free certification track). See: http://ipv6.he.net/certification
Good point, my summary of the situation and development was clearly too sarcastic and a wrong description of the timeline. (I do maintain that MAC-SLAAC and privacy extensions live at opposite sides of the continuum ).
That seems helpful for some applications. My use-case for accessible addresses is using dynamic DNS (my ISP unhelpfully insists upon renewing/exchanging my IPv6 prefix once per day) to make my system reachable from the outside, but then the fact that there is a DNS server telling anybody bothering to ask my stable "random" address I am not that much better off than with a fixed interface identifier of my own making but I guess that being accessible from the outside just carries some risk.
Yes, that's annoying. Funny thing is that some people request this for privacy reasons. Go figure.
I had the luxury of getting to implement the system which assigns prefixes to our users, and one of my concerns was to make the allocations as stable as possible. I had been testing for a while at home and gone through a couple of renumbering events due to bad planning. That was surprisingly hard. A real home network will end up hard coding addresses all over the place. Unless you're perfect and always script everything you do instead of taking a shortcut to configure your printer.
There are a few real world limits, like no one wanted millions of new routes floating around in the network. But as long as the physical link to the user site ends up in the same router, then we keep the prefix stable.
And lazy as I am, I thought that there's no need to implement variable prefix length until it's required by something or someone. 10 years later, that still hasn't happened. So everyone are enjoying their /48s
the cynic in me suggests this maybe to "encourage" breaking on purpose to make sure no one is running servers on consumer ip ranges, and they get to sell it as a PR "privacy" bonus... Just like how ISPs used to block anyone running web servers or email servers at home.
maybe I'm just grumpy old and bitter... or maybe I'm right... who knows.
I am getting one static IPv4 and a static IPv6 subnet from my ISP, I tried to configure IPv6, but ended up just using IPv4 with NAT.
Will probably give it a new try, but I disagree that it is easier to configure..
Not really. The 2 protocols aren't compatible with each other; both ends must use the same to exchange packets. Also, there's a lot of hoarding going on in the ipv4 space. The price of ipv4 addresses on the secondary market doubled in 2020 from around $25 per address to $50 per address where it remains now. A /8 block would cost around $839 million at that price, and a large ISP network realistically needs one or two /8 blocks to avoid the need for carrier grade nat.
IMHO they should take that enormous DoD ipv4 block and break it up into 22 bit blocks which may ONLY be used for NAT64 endpoints and contract them out to ISPs under that restriction. Every ISP that gets one must offer a /56 to each user by default, and a static /48 to anyone who requests it...
They (the DoD) "own" it - it's not "registered with a RIR". A lot of the original /8 owners were given their space by RFC. This also means, there's no RIR to handle such "subnetting" unless the space is "surrendered" to an RIR. Clearly you understand with IPv4 exhaustion why that's not wise for any /8 owner (who actually uses their IP space) at this time.
FYI, the Amateur Radio group that "owned" all of 44/8 did sell some space to Amazon...didn't really help with exhaustion much, did it?
The same entity "contracting them" is the same as the one that has exhausted their remaining IP space.
How would this differ from Carrier-grade NAT, which doesn't require an ISP to configure a specialized routing instance?
Why do propose special IP space - or is this assumption based on a premise that the ISP has 0 IPv4 addresses at their disposal?
Working for an ISP created after ARIN Exhaustion began - in fact, we were issued our ASN and IPV6 space with the last blocks of IPv4 before Emergency IPv4 phase began in N. America and the Caribbean - we're looking to IPv6 and Carrier-grade NAT setups in the future.
Users needing IPv4 services are given an IPv4 address and it is NATed/port forwarded for them - which is still problematic for OEMs who only provide support as if the public IP is issued/assigned on said server/device. IP space == physical delivery too, so in a fiber network few customers do so ($$$).
ISPs are trying to get away from translating space and the such.
I'm customer of a (new'ish, founded 2011) fibre ISP which sits on 32'768 IPv4 addresses for their ~1.5 million users, cgNAT for IPv4 and a semi-static /56 IPv6 prefix are the result. Accordingly I am using IPv6 for all my incoming needs (wireguard in particular), alternatives - none (no way to pay extra for a real IPv4 address (apart from tunneling via external commercial services), only switching to a VDSL based ISP would give me a (dynamic) IPv4 address). This is not a rare situation in Europe for customers of 'newer' ISPs (cable/ fibre/ wifi, …), who came late to the party and aren't sitting on large pools of established address space.
Exactly, my point is to take that big DoD space and turn it into a useful way to create new IPv6 ONLY ISPs. WISPs and local community fiber providers and soforth. There is really ZERO reason to be setting up a NEW ISP that provides ipv4 at all. Look at T-Mobile, their mobile network works very well. Android and iOS systems both work perfectly fine with ipv6 only. Mac, Windows, and Linux all work great with ipv6 only. The only thing that usually doesn't work well is desktop PC games, maybe some consoles. Game guys seem to be head in the sand, but they actually could benefit the most from ipv6 end to end...
We're talking about the US Federal govt, they can easily create contracts with RIRs to administer these to global ISPs who are contractually obligated to use them for IPv6 only transition for NAT64 only endpoints. It would I think dramatically accelerate the conversion to ipv6. Govts should be about public goods such as creating a world of effectively unlimited addresses (ie. ipv6)
That sounds pretty neat! Regarding privacy of prefixes, I would love if my ISP kept the prefix stable if not too much hassle for them, for the 'prefixes leak privacy' crowd they could offer a manal 'get new prefix' method on their customer support site.
Could be, but dynamic DNS is a thing already so this does not really
I somehow feel that the DoD might not be all to happy about that. (they might actually use some of the space as well)... why not grab somebody elses allocations while we are at it? Kidding aside, it would offer a considerably fairer playing field if we re-allocated IP space between ISPs on a regular basis. ISPs then can decide how to split their allocations into static, dynamic and shared IPs. Mind you this idea is only slightly less realistic than the DoD one.