In message <54f4d7bb.3050...@gmail.com>, Brian E Carpenter writes: > Hi Toerless, > On 03/03/2015 10:23, Toerless Eckert wrote: > > 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 ? > > http://tools.ietf.org/html/rfc7010 is the gap analysis, but for > enterprise networks. I think what Dave is actually saying is that > complex home networks of the future (which is where he already lives) > inherit many of these problems, with difference that renumbering > will be imposed by the ISP, so the element of choice and planning > that an enterprise network has is missing.
What we really should be telling ISPs is that renumber events should be make before break. There is zero reason other plain poor customer service to not do this. I can understand why this is done in IPv4 (not enough address space) but this does not apply to IPv6. If the equipement / software ISP's are using can't support multiple prefixes then log fault reports with the suppliers. Multiple prefixes have been part of IPv6 from the very beginning. > Somebody needs to work on RFC7010-for-homenet, I guess. > > (Curtis is right, of course: if a network is designed and > managed with renumbering treated as an expected event, life > would be better.) > > Brian > > > > > 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.gmai > l.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 e > ffects of re-establishing TPC sessions, or updating > >>>>>>>> dynamic naming services, or having to run an L2 overlay network ever > ywhere, 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 depende > nce 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 a > ny 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 > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
