This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] Re: [ipv6-wg] IPv6 PI
- Previous message (by thread): [address-policy-wg] Re: [ipv6-wg] IPv6 PI
- Next message (by thread): [address-policy-wg] Re: [ipv6-wg] IPv6 PI
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
william(at)elan.net
william at elan.net
Wed Nov 30 10:53:49 CET 2005
On Wed, 30 Nov 2005, Geoff Huston wrote: > At 03:17 AM 30/11/2005, Randy Bush wrote: >> >> Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these >> real >> >> issues for a good reason. >> > Regardless of the efforts, from a provider POV it's only "work in >> > progress". >> >> one of the key points from the nanog session was that shim6 is the >> *wrong* work in progress. what is needed is _site_ multi-homing, >> not host multi-homing. Yes, well if it goes forward, it may well end up being used for setting up site-multihoming: http://www.ietf.org/mail-archive/web/architecture-discuss/current/msg00095.html and will be seen as friendly and right solution (on what "friendly" and "right" can mean seen below). > "wrong"? "right"? > > Usual response - if you believe that there is a better way of doing this > work through the issues here, then write up an approach, gather support, get > peer review etc etc. > > As I said at NANOG, part of the problem with distributed models where there > is action at a distance is to understand and clearly identify instances of > gratuitous packet header rewriting by hostile agents as compared to packet > rewriting by agents who believe that they are doing this in a friendly and > helpful fashion. This becomes a challenging problem,of course. If its hostile or friendly behavior is in the eye of the beholder - but in fact it may not even be only one side or the other for the same person. If I sit under a NAT and it prevents my application from running, I'm hostile to that behavior. But same NAT box may well be protecting my home network from intrusion and allowing me to have multiple computers connected through the same dsl/cable/wireless connection, so I'd view it as a friendly. Since most people don't notice its hostile behavior (due to kind of applications they run) and all notice its friendly behavior it will overall be seen as a friend and "right" solution. So is there better way to do it and without NAT? Of course there is - have real firewall and have block of ips - but NAT is winning as a business case because it can do those several friendly things well for almost everyone and without dependence on network provider and those few users who are inconvenienced and their application are viewed as minor percentage and not a problem in the overall business case. So business case won but IETF end-end tcp/ip architecture broken ... > I don't think any single approach today is the one true right approach at > this point, but unless we explore this space with some diligence, Diligence is the right word. But is it really the size of the routing table that we're being most concerned (considering #of routes in ipv6 will most definitely be smaller then with ipv4 because of less fragmentation - generally one ip block per ASN) or business case of users who do not want to be dependent on IP provider and RIR to be able to multihome? And should due diligence be applied so that proposed solution both makes sense to do for those who will use it (i.e. small businesses in case of shim6) an does not break applications when that is done? -- William Leibzon Elan Networks william at elan.net
- Previous message (by thread): [address-policy-wg] Re: [ipv6-wg] IPv6 PI
- Next message (by thread): [address-policy-wg] Re: [ipv6-wg] IPv6 PI
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]