Re: [BEHAVE] Handwaving? [Re: where to have the NAT66 discussion (was Re: Please move this thread to BEHAVE mailing list ... )]
On 2 dec 2008, at 20:31, Ralph Droms wrote: Iljitsch - I understand the theory behind what you're describing...in practice, it's a hard problem to know where all the prefixes are that should be changed; worse yet, it's hard to know which prefixes in which parts of the configuration should be replaced with new prefixes, and which shouldn't be changed. It doesn't have to be if it's designed for this. I know a few years back Cisco routers had a limited capability in this area: ! interface Ethernet1 ipv6 address autoconfig ipv6 dhcp client pd dhcpv6prefix ! interface Ethernet2 ipv6 address dhcpv6prefix 0:0:0:A0::/64 eui-64 ! (The prefix is put in the variable dhcpv6prefix which is then ORed with the prefix 0:0:0:a0::/64 later.) Seems to me this can easily be extended to all places where addresses appear. But note that I was specifically addressing the presence vs absense of NAT in relationship to renumbering. All the difficult stuff is other people not directly under your control having pointers to your addresses, this is the same with or without NAT. most of the places where IP addresses are configured were never designed with renumbering or any sort of signaling in mind, and will be very difficult to automate. Right, so vendors need to step up. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Handwaving? [Re: where to have the NAT66 discussion (was Re: Please move this thread to BEHAVE mailing list ... )]
On 2 dec 2008, at 5:37, Keith Moore wrote: I don't think it's just that the multi-prefix model is unfamiliar. There's plenty of reason to believe that it won't work well. Static address selection rules, no way for hosts to know which prefixes will work better, inability of most existing transport protocols to fail over to alternate addresses. One way to fix that would be multipath transport protocols. Rather than try to guess what works best, just use all of them (or at least several) and get better performance without having to make difficult choices. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Handwaving? [Re: where to have the NAT66 discussion (was Re: Please move this thread to BEHAVE mailing list ... )]
At 2:57 AM -0800 12/2/08, Iljitsch van Beijnum wrote: On 2 dec 2008, at 5:37, Keith Moore wrote: I don't think it's just that the multi-prefix model is unfamiliar. There's plenty of reason to believe that it won't work well. Static address selection rules, no way for hosts to know which prefixes will work better, inability of most existing transport protocols to fail over to alternate addresses. One way to fix that would be multipath transport protocols. Rather than try to guess what works best, just use all of them (or at least several) and get better performance without having to make difficult choices. It's not clear to me from the above whether you mean something like use SCTP, something like build ICE-like candidate selection algorithms into the transport protocols, so that the best path gets selected, or run all available transports from all available flow endpoints for as long as the flow lasts. Care to clarify? Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Handwaving? [Re: where to have the NAT66 discussion (was Re: Please move this thread to BEHAVE mailing list ... )]
On 2 dec 2008, at 18:46, Ted Hardie wrote: One way to fix that would be multipath transport protocols. Rather than try to guess what works best, just use all of them (or at least several) and get better performance without having to make difficult choices. It's not clear to me from the above whether you mean something like use SCTP, Note that although SCTP is aware of multiple addresses, it won't actually use them concurrently. What I have in mind is a TCP that can use multiple paths at the same time. For the purposes of this discussion that would have to be a multiaddressing aware multipath TCP or a multipath TCP integrated with shim6/MIPv6. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Handwaving? [Re: where to have the NAT66 discussion (was Re: Please move this thread to BEHAVE mailing list ... )]
Excerpts from Iljitsch van Beijnum on Tue, Dec 02, 2008 11:57:07AM +0100: On 2 dec 2008, at 5:37, Keith Moore wrote: I don't think it's just that the multi-prefix model is unfamiliar. There's plenty of reason to believe that it won't work well. Static address selection rules, no way for hosts to know which prefixes will work better, inability of most existing transport protocols to fail over to alternate addresses. One way to fix that would be multipath transport protocols. Rather than try to guess what works best, just use all of them (or at least several) and get better performance without having to make difficult choices. This doesn't help with site renumbering problems, just endpoint renumbering. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Handwaving? [Re: where to have the NAT66 discussion (was Re: Please move this thread to BEHAVE mailing list ... )]
On 2 dec 2008, at 20:02, Scott Brim wrote: One way to fix that would be multipath transport protocols. Rather than try to guess what works best, just use all of them (or at least several) and get better performance without having to make difficult choices. This doesn't help with site renumbering problems, just endpoint renumbering. NAT also helps very little with renumbering. The only thing that it buys you is that you don't have to renumber routers and other devices that have their addresses configured staticially sitting behind the NAT. But routers can receive prefixes over DHCPv6 and then use those prefixes to number their stuff rather than have this done by hand, so there is _very_ little need for static address configuration. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Handwaving? [Re: where to have the NAT66 discussion (was Re: Please move this thread to BEHAVE mailing list ... )]
Iljitsch - I understand the theory behind what you're describing...in practice, it's a hard problem to know where all the prefixes are that should be changed; worse yet, it's hard to know which prefixes in which parts of the configuration should be replaced with new prefixes, and which shouldn't be changed. In theory (where theory == reductio ad absurdum), renumbering is just a network and host management problem. In practice, while SLAAC and prefix delegation address some (I'll wager a fairly small percentage; for that matter, DHCPv4 addressed the host renumbering problem years ago) renumbering problems, most of the places where IP addresses are configured were never designed with renumbering or any sort of signaling in mind, and will be very difficult to automate. - Ralph On Dec 2, 2008, at Dec 2, 2008,2:11 PM, Iljitsch van Beijnum wrote: On 2 dec 2008, at 20:02, Scott Brim wrote: One way to fix that would be multipath transport protocols. Rather than try to guess what works best, just use all of them (or at least several) and get better performance without having to make difficult choices. This doesn't help with site renumbering problems, just endpoint renumbering. NAT also helps very little with renumbering. The only thing that it buys you is that you don't have to renumber routers and other devices that have their addresses configured staticially sitting behind the NAT. But routers can receive prefixes over DHCPv6 and then use those prefixes to number their stuff rather than have this done by hand, so there is _very_ little need for static address configuration. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
