Would any of those rfc explain to me what the problems with renumbering in a homenet are that Fave tried to avoid by doing NAT ? And how those issues can not be mitigated by better workarounds than NAT ?
On Sun, Mar 01, 2015 at 02:24:08PM +1300, Brian E Carpenter wrote: > 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 -- --- Toerless Eckert, eck...@cisco.com _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
