Admittedly 6renum was targetted at enterprise networks, partly because of the observation that homenets renumber anyway after every power cut. But we have spent a lot of cycles on this issue.
http://tools.ietf.org/html/rfc4192 http://tools.ietf.org/html/rfc5887 http://tools.ietf.org/html/rfc6866 http://tools.ietf.org/html/rfc6879 http://tools.ietf.org/html/rfc7010 and maybe it's time to revive https://tools.ietf.org/html/draft-liu-opsarea-ipv6-renumbering-guidelines Brian On 01/03/2015 12:40, Curtis Villamizar wrote: > In message > <caa93jw4tumfm_lvzkrx7ark2z+hwtw5jboenpvfejut4l9t...@mail.gmail.com> > Dave Taht writes: > >> On Fri, Feb 27, 2015 at 2:00 PM, Curtis Villamizar >> <cur...@ipv6.occnc.com> wrote: >>> In message <54ee258e.8060...@gmail.com> >>> Brian E Carpenter writes: >>> >>>> On 26/02/2015 05:14, Mikael Abrahamsson wrote: >>>>> On Wed, 25 Feb 2015, Ray Hunter wrote: >>>>> >>>>>> That way the devices can roam at L3, without all of the nasty side >>>>>> effects of re-establishing TPC sessions, or updating >>>>>> dynamic naming services, or having to run an L2 overlay network >>>>>> everywhere, or having to support protocols that require a >>>>>> specialised partner in crime on the server side (mTCP, shim6 et al). >>>>> >>>>> It's my firm belief that we need to rid clients of IP address dependence >>>>> for its sessions. Asking clients to participate in HNCP >>>>> only addresses the problem where HNCP is used. >>>>> >>>>> Fixing this for real would reap benefits for devices moving between any >>>>> kind of network, multiple providers, mobile/fixed etc. >>>> >>>> Violent agreement. This is not a homenet problem; it's an IP problem. >>>> In fact, it's exactly why IP addresses are considered harmful in >>>> some quarters. Trying to fix it just for homenet seems pointless. >>>> http://www.sigcomm.org/ccr/papers/2014/April/0000000.0000008 >>>> >>>> Brian >>> >>> >>> Brian, >>> >>> Seriously - your paper may be overstating the problem. At least if we >>> discount IPv4 and in doing so eliminate NAT we solve a lot of problems >>> that never should have existed in the first place. If we carry NAT >>> over to IPV6, then shame on us. >> >> I am sorry, I no longer share this opinion. The pains of renumbering >> someones entire home network every time the ISP feels like it, given >> the enormous number of devices I have encountered that don't handle it >> well, are just too much to bear. > > I renumbered 140.222/16 into 147.225/16 in the mid 1990s (T3-NSFNET to > ANSNET as part of the NSFNET decommissioning). Not by myself of > course, but there were only a few of us on this. It wasn't all that > bad and we had about 2,000 things to renumber in hundreds of > locations, many of them not manned. Shell scripts and ksh (kerberized > rsh, not the Korn shell) made it simpler. The worst was Cisco routers > and various old DSU/CSU and other commercial stuff since you had to > use "expect" scripts on their CLI rather than just something of the > form "ksh fqdn -l root ifconfig newaddr/mask alias" People with root > on their workstation that didn't give us acess were given notice. We > used interface aliases and gradually took down the old aliases and > subnet addresses. Nothing critical was affected. It took a day or > two, then bake time, then less than a day to remove aliases. > > OTOH - Most homes can't run two prefixes for a week or two before > taking the old prefix down. And lots of consumer devices don't do > aliases. But now days there is DHCP which didn't exist then (and > ICMPv6 RS/RA and SLAAC). > > Are you having problems with the provider not giving you a static IPv6 > prefix, but rather changing it on a whim? > > I also renumbered my home net multiple times, but again, not much > pain. Only a few consumer gadgets here have fixed addresses (one > because it never renewed DHCP leases and therefore needed a fixed > address, but that has since been tossed in e-waste recycling). > >> The next version of cerowrt will do translation from the external IPv6 >> address range to a static internal one (or ones, in the case of >> multiple egress gateways), and lacking a standard for such will use >> fcxx/8 addressing. I will make it be an option for people to turn off, >> but I've had it with being renumbered. > > Are you suggesting that we add NAT to IPv6? [I ask with disbelief.] > > I would definitely be turning that off since I have a plenty big and > very static IPv6 prefix. I also have a (tiny) static IPv4 prefix so I > have no choice but to IPv4 NAT due to its tiny size. > > A better option might be to use something that switches over faster > than a DHCP lease times of days. It seems that ICMPv6 RA can be sent > with prefix prefix information TLV with valid lifetime and/or > preferred valid lifetime of zero. This is in RFC 4861 on Page 55: > > - If the prefix is already present in the host's Prefix List as > the result of a previously received advertisement, reset its > invalidation timer to the Valid Lifetime value in the Prefix > Information option. If the new Lifetime value is zero, time-out > the prefix immediately (see Section 6.3.5). > > Would that help? > > Also, stateful DHCPv6 can invalidate leases (me thinks)? Maybe > DHCPv4? Am I mistaken about that? > >> I am sure this will break stuff, and I don't know what all it will do, >> and I intend to find out. > > Just breaks the end-to-end principle and requires rendezvous and all > that ugliness. > > IMHO it would be better to send an immediate RA with a zero lifetime > on the old prefix and a normal lifetime on the new prefix. If hosts > don't do the right thing they are in violation of RFC 4861. > > OTOH, invalidating a DHCP lease would not do what we want here. > >> Until some far off day where we have stable name to ipv6 address >> mapping, and vice versa, it is otherwise impossible to have useful >> ipv6 based services inside the home or small business. > > Oh yeah. And then there is DNS. Maybe it would be better to keep a > short non-zero valid lifetime (longer than DNS TTL) and a preferred > valid lifetime of zero on that old prefix so it sticks around and is > usable locally but not preferred so not used for outgoing > connections. Good reason to not set DNS TTL to days. That way hosts > with cached DNS mapping to the old addresses will still work. > >>> If we get rid of NAT a big part of the problem just goes away. No >>> alternate spaces, kludgy rendezvous mechanisms, etc. Using an address >>> on the loopback gets rid of the multiple interface problem and where >>> it really matters (ISP router and ISP or DS server reachability) this >>> has been done with configuration for two decades. The multihoming >>> failover or roaming are a bit more difficult but things MPTCP is >>> supposed to address. >>> >>> Curtis > > You want to keep NAT for IPV6? Really? > > Curtis > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
