On 03/03/2015 13:26, Curtis Villamizar wrote:
> 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.
>>
>> Somebody needs to work on RFC7010-for-homenet, I guess.
>
> Its zero conf. It just happens. Seriously.
Well, Dave is saying he's tried and it doesn't. Whether that
means he has a printer with a manually configured non-ULA IPv6
address, or something else, I don't know, but we need to
understand.
Brian
>
> OTOH, if there are devices with configured addresses then it would be
> nice if the person running the network knew what they were, where
> they were located, and how to access them to make changes.
>
>> (Curtis is right, of course: if a network is designed and
>> managed with renumbering treated as an expected event, life
>> would be better.)
>>
>> Brian
>
> Its really not a matter of treated renumbering as an expected event.
> Good network planning results in knowing how you've allocated subnets,
> which servers were given fixed addresses, and what DHCP pools exist.
> Good network management involves also checking to see that hosts you
> see for fixed addresses you don't know about including those within
> the pools (no DHCP lease in the logs but something there at the top
> range of the pool). Its also nice to know when a rogue host or DHCP
> server shows up and have the means to isolate its physical location.
> For example, a box that went nuts and started spewing packets.
>
> That type of good planning and good management leads to a simple and
> straightforward renumbering as long as there is a grace period for the
> transition. If maintenance of configs is automated, then the renumber
> can be done in record time.
>
> Curtis
>
>
>>> 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
>
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
