[ipv6-wg] unsubscribe jkuijer@dds.nl

Citeren ipv6-wg-request@localhost:

> Send ipv6-wg mailing list submissions to
> 	ipv6-wg@localhost
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://www.ripe.net/mailman/listinfo/ipv6-wg
> or, via email, send a message with subject or body 'help' to
> 	ipv6-wg-request@localhost
>
> You can reach the person managing the list at
> 	ipv6-wg-admin@localhost
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ipv6-wg digest..."
>
>
> Today's Topics:
>
>    1. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Per Heldal)
>    2. unsubscibe jkuijer@localhost (jkuijer@localhost)
>    3. Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 (Florian
> Weimer)
>    4. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Randy Bush)
>    5. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Geoff Huston)
>    6. Re: Re: [address-policy-wg] Re: Andre's guide to fix
>        IPv6 (Geoff Huston)
>    7. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Geoff Huston)
>    8. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (william(at)elan.net)
>    9. Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 (Max Tulyev)
>
> --__--__--
>
> Message: 1
> From: "Per Heldal" heldal@localhost
> To: "Salman Asadullah" sasad@localhost
> Cc: "ipv6-wg@localhost" ipv6-wg@localhost, "address-policy-wg@localhost"
>    address-policy-wg@localhost
> Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI
> Date: Tue, 29 Nov 2005 12:21:52 +0100
>
>
> On Mon, 28 Nov 2005 15:55:16 -0800, "Salman Asadullah" sasad@localhost
> said:
> > You seem to be far away from the ground realities.
> >
> > 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". Make sure your preferred technology is implemented across all
> platforms and accompanied by solutions for traffic-engineering,
> filtering and other issues. Then you may have a viable alternative to
> present to the operators community. Don't expect anybody to adopt new
> technologies unless they represent some progress.
>
> I'm not saying that shim6 is DOA. It *may become* an alternative, but it
> *is not*. Unless you can convince content-providers to trust their
> upstream to provide redundancy and thus eliminate the need for end-site
> multihoming you have the following realistic short-term alternatives:
>
>  * Keep ipv6 experimental and postpone operational
>    deployment until there's a good technical solution
>    to the multi-homing problem or a way to eliminate
>    the DFZ and the related concerns about routing-
>    table size.
>
>  * Adopt a PI policy for v6 similar to the current
>    v4-policy, and hope that moore can keep up with
>    the growth of the routing-table.
>
> From there policies will have to evolve, along with the development of
> new technology. Evolution is a perpetual process, not a project with a
> finite deadline.
>
> PS! am I missing something, or is IETF/IAB trying to copy the ITU in the
> way they produce paper-standards? Is that really such a good idea?
>
> //per
> --
>   Per Heldal
>   heldal@localhost
>
>
> --__--__--
>
> Message: 2
> Date: Tue, 29 Nov 2005 12:25:08 +0100
> From: jkuijer@localhost
> Subject: [ipv6-wg] unsubscibe jkuijer@localhost
>
> Citeren ipv6-wg-request@localhost:
>
> > Send ipv6-wg mailing list submissions to
> > 	ipv6-wg@localhost
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > 	http://www.ripe.net/mailman/listinfo/ipv6-wg
> > or, via email, send a message with subject or body 'help' to
> > 	ipv6-wg-request@localhost
> >
> > You can reach the person managing the list at
> > 	ipv6-wg-admin@localhost
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of ipv6-wg digest..."
> >
> >
> > Today's Topics:
> >
> >    1. Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 (McTim)
> >    2. Re: [address-policy-wg] Re: Andre's guide to fix IPv6 (Geoff Huston)
> >    3. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Randy Bush)
> >    4. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Andre Oppermann)
> >
> > -- __--__--
> >
> > Message: 1
> > Date: Tue, 29 Nov 2005 07:19:49 +0300
> > From: McTim dogwallah@localhost
> > To: =?ISO-8859-1?Q?J=F8rgen_Hovland?= jorgen@localhost
> > Subject: Re: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix
> IPv6
> > >
> > hiya,
> >
> > (removed address-policy-wg from the cc:)
> >
> > On 11/28/05, J=F8rgen Hovland jorgen@localhost wrote:
> > >
> > > -----Original Message-----
> > > From: McTim [
	    
	    
]
> > > >
> > > >#2 sounds like PI to me. What have I missed?
> > >
> > > Hello McTim,
> > > You are correct. That's why I wrote PI in the email:-).
> >
> > I guess I misread the below wrong then ;-)
> >
> > J=F8rgen Hovland wrote:
> >
> > >> -
> > >> 1. No PI. _Only_ network operators get a prefix.
> >
> > > It is an attempt to suggest an alternative idea to the PI discussion.
> > > Don't get me wrong. I am for PI. This idea is perhaps a bit more
> > > hierarchical instead of the standard flat one. Just making sure we have
> > > thought of everything before we reach consensus
> >
> > I am sure thiat consensus will take a very long tiime on this one!  We
> > will probably have to talk about grotopological v6 adressing (as they
> > are doing on the ARIN ppml) and a host of other issues.   I reckon we
> > ought to wait for shim6 to do their work as well.
> >
> > > because this PI discussion
> > > is very important to ipv6.
> >
> > v. true.
> >
> > --
> > Cheers,
> >
> > McTim
> > $ whois -h whois.afrinic.net mctim
> >
> >
> > -- __--__--
> >
> > Message: 2
> > Date: Tue, 29 Nov 2005 10:15:27 +1100
> > To: =?iso-8859-1?Q?J=F8rgen?= Hovland jorgen@localhost,
> >    address-policy-wg@localhost, ipv6-wg@localhost
> > From: Geoff Huston gih@localhost
> > Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6
> >
> > At 03:37 AM 29/11/2005, J=F8rgen Hovland wrote:
> > >----- Original Message ----- From: "Florian Weimer" fw@localhost
> > >Sent: Saturday, November 26, 2005 4:00 PM
> > >
> > >
> > >>* Jeroen Massar:
> > >>
> > >>>>1. Make /32 the only routable entity so we can use perfect match in
> > >>>>    the DFZ instead of longest-prefix match.
> > >>>
> > >>>What about the organizations that have say a /19, want them to inject
> > >>>all their more specific /32's?
> > >>
> > >>You can inject a /19 as 8192 /32s.  Shouldn't make a difference if the
> > >>/19 is really used.
> > >>
> > >>At this stage, it's probably not too wise to embed the /32--/48--/64
> > >>in silicon, but vendors will undoubtedly do this if they can save a
> > >>few bucks and current policies remain as inflexible as they are.
> > >
> > >Hi,
> > >Perfect match is faster but far from better. What I think perhaps would
> be=
> > =20
> > >interesting to see in the future with regards to IPv6 and PI is the=
> >  following:
> > >
> > >1. No PI. _Only_ network operators get a prefix.
> > >2. Customers of network operators can at any time change provider and
> take=
> > =20
> > >their assigned prefix with them. The new provider will announce it as a=20
> > >more specific overriding the aggregate. If the customer decides to get=20
> > >multiple providers, then the network operator with the /32 could also=20
> > >announce a more specific.
> > >
> > >In the country I live in I can change telecom provider and take my
> phone=20
> > >number with me to the new provider. Why shouldn't I be able to do that=20
> > >with internet providers?
> > >Yes, it will somehow create millions/billions of prefixes (atleasat
> with=20
> > >todays routing technology/protocols). Network operators should be able to=
> > =20
> > >handle that hence rule #1.
> >
> >
> > Interesting - it will work for a while, and then you will get to the limit=
> > =20
> > of deployed capability of routing.
> >
> > Then what?
> >
> >     Geoff
> >
> >
> >
> >
> >
> > -- __--__--
> >
> > Message: 3
> > From: Randy Bush randy@localhost
> > Date: Mon, 28 Nov 2005 21:49:17 -1000
> > To: Salman Asadullah sasad@localhost
> > Cc: Roger Jorgensen rogerj@localhost,
> >     Oliver Bartels oliver@localhost,
> >     "ipv6-wg@localhost" ipv6-wg@localhost,
> >     "address-policy-wg@localhost" address-policy-wg@localhost,
> >     roger@localhost
> > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI
> >
> > > Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real
> > > issues for a good reason.
> >
> > i gather that the message that leslie daigle was given at the
> > last nanog was not well-transmitted to the ietf.  no big
> > surprise.
> >
> > you may want to look at http://nanog.org/mtg-0510/real/ipv6-bof.ram
> >
> > randy
> >
> >
> > -- __--__--
> >
> > Message: 4
> > Date: Tue, 29 Nov 2005 10:13:39 +0100
> > From: Andre Oppermann oppermann@localhost
> > To: Salman Asadullah sasad@localhost
> > CC: Roger Jorgensen rogerj@localhost,
> >  	Oliver Bartels oliver@localhost,
> >  	"ipv6-wg@localhost" ipv6-wg@localhost,
> >  	"address-policy-wg@localhost" address-policy-wg@localhost,
> >  	roger@localhost
> > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI
> >
> > Salman Asadullah wrote:
> > >
> > > You seem to be far away from the ground realities.
> > >
> > > Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real
> > > issues for a good reason.
> >
> > Neither Multi6 nor SHIM6 are even in an draft RFC state yet and to be
> > workable they'd have to be implemented on every end-host out there.
> > That is every operating system in sufficient existence.  That puts IPv6
> > even further in the already distant future considering common OS upgrade
> > and replacement cycles.
> >
> > Second this doesn't solve the renumbering problem.  Renumbering is not
> > just giving hosts new IP addresses but alost managing DNS and Firewalls.
> > No even remotely workable and scaleable solution has been presented yet.
> >
> > So nice try but no cookie.
> >
> > --
> > Andre
> >
> >
> > > Regards,
> > > Salman
> > >
> > > At 10:55 AM 11/25/2005 +0100, Roger Jorgensen wrote:
> > >
> > > > On Thu, 24 Nov 2005, Oliver Bartels wrote:
> > > > > On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote:
> > > > <snip>
> > > > > If IPv4 offers PI = provider _independence_ and multihoming
> > > > > and IPv6 doesn't, then IPv4 is obviously the better solution for
> > > > > those who requires this functionallity.
> > > > >
> > > > > Thus they won't use IPv6.
> > > > >
> > > > > Please keep in mind: The _customer_ votes, not you, not me.
> > > > >
> > > > > And as the majority of the large and a significant portion of medium
> > > > > size businesses are obviously not willing to accept an IP protocol
> not
> > > > > providing this functionallity, IPv6 will remain at it's current
> status:
> > > > >
> > > > > A technical playground for technically interested people.
> > > >
> > > > a very true point in one way but that is again as I see it, we're still
> > > > thinking IPv4 when talking IPv6.
> > > >
> > > > Why do they need multihoming and PI? They don't trust the ISP and
> vendors
> > > > to deliver them uptime and freedom... isn't this a problem the ISP and
> > > > vendors should try to solve? Of course, the idea of easy renumbering
> was
> > > > suppose to solve this but again, we're thinking IPv4 so it's not easy
> to
> > > > understand.
> > > >
> > > > Again, we don't need PI space and multihoming, what we need are a way
> to
> > > > give the users and GOOD connectivity (uptime, speed etc) and make it
> easy
> > > > for them to switch providers as they see fit.
> > > >
> > > >
> > > >
> > > > <snip>
> > > > >
> > > > > Hmm, please let me translate:
> > > > > "Even if the car doesn't drive and the engine doesn't deliver a
> single
> > > > > horse power at the wheels, drop the thought about driving,
> > > > > start to think about other way to use the possibility this great car
> > > > > gives us."
> > > > >
> > > > > Sound like newspeak:
> > > > > If we _think_ we can't solve the problem, drop discussing the
> problem.
> > > >
> > > > for several years this discussion have been going on, still no real
> > > > solution. IPv6 give us the freedom todo ALOT of things, USE those
> > > > possibilities, if we have to change how IP are done, some TCP headers
> > etc,
> > > > then do it... propose a good idea and prove it. That could give us
> > > > multihoming. Actually there is a master thesis about howto create
> > > > connectivity for TCP session even if one of the links went down, the
> > > > session just used another IP (1)... the user don't notice anything
> > > > either and it have zero problem working with standard tcp-stacks since
> it
> > > > use the extended header of IPv6.
> > > >
> > > > That's just ONE of many possible ways...
> > > >
> > > >
> > > >
> > > > (1) it's a master thesis writting by a student related to University of
> > > > Tromsø as part of the Pasta project, www.pasta.cs.uit.no
> > > >
> > > > --
> > > >
> > > > ------------------------------
> > > > Roger Jorgensen             |
> > > > rogerj@localhost       | - IPv6 is The Key!
> > > > http://www.jorgensen.no     | roger@localhost
> > > > -------------------------------------------------------
> >
> >
> >
> >
> > End of ipv6-wg Digest
> >
>
>
>
>
> --__--__--
>
> Message: 3
> From: Florian Weimer fw@localhost
> To: Geoff Huston gih@localhost
> Cc: =?iso-8859-1?Q?J=F8rgen?= Hovland jorgen@localhost,
>   address-policy-wg@localhost,  ipv6-wg@localhost
> Subject: Re: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6
> Date: Tue, 29 Nov 2005 15:26:53 +0100
>
> * Geoff Huston:
>
> > Interesting - it will work for a while, and then you will get to the limit
> > of deployed capability of routing.
> >
> > Then what?
>
> You buy new routers.
>
> What's next?  Do you plan to lobby Hollywood to reduce the number of
> movies create per year, so that your customers have fewer of them to
> download, and the capacity of your pipes is not exceeded?
>
>
> --__--__--
>
> Message: 4
> From: Randy Bush randy@localhost
> Date: Tue, 29 Nov 2005 06:17:54 -1000
> To: Per Heldal heldal@localhost
> Cc: Salman Asadullah sasad@localhost,
>     ipv6-wg@localhost,
>     address-policy-wg@localhost
> Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI
>
> >> 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.
>
> randy
>
>
> --__--__--
>
> Message: 5
> Date: Wed, 30 Nov 2005 05:34:05 +1100
> To: Randy Bush randy@localhost, Per Heldal heldal@localhost
> From: Geoff Huston gih@localhost
> Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI
> Cc: Salman Asadullah sasad@localhost, ipv6-wg@localhost,
>    address-policy-wg@localhost
>
> 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.
>
> "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.
>
> 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, allow for
> experimentation and keep an open mind on this work then you are going to
> get intractably wedged between the desire for greater flexibility in the
> use of addresses as a form of semi-persistent endpoint identifiers  and the
> desire for reduced flexibility in the use of addresses as forwarding tokens
> in order to keep the routing space confined to readily computable dimensions.
>
> But of course _all_ this will be solved in MPLS - right? :-)
>
>   Geoff
>
>
>
>
>
> --__--__--
>
> Message: 6
> Date: Wed, 30 Nov 2005 05:36:11 +1100
> To: Florian Weimer fw@localhost
> From: Geoff Huston gih@localhost
> Subject: Re: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix
>   IPv6
> Cc: =?iso-8859-1?Q?J=F8rgen?= Hovland jorgen@localhost,
>    address-policy-wg@localhost, ipv6-wg@localhost
>
> At 01:26 AM 30/11/2005, Florian Weimer wrote:
> >* Geoff Huston:
> >
> > > Interesting - it will work for a while, and then you will get to the
> limit
> > > of deployed capability of routing.
> > >
> > > Then what?
> >
> >You buy new routers.
>
>
> So what you are saying is that _I_ want address portability and _you_ have
> to buy new routers.
>
>
> Well that sure works for me! How's the chequebook feeling on your side?
>
> (I'm not convinced that you've selected the best of business models, as
> there does appear to be a significant inconsistency going on in your model
> in that cost and benefit are not related all that well.)
>
> Geoff
>
>
>
> --__--__--
>
> Message: 7
> Date: Wed, 30 Nov 2005 06:01:56 +1100
> To: Andre Oppermann oppermann@localhost, Salman Asadullah
> sasad@localhost
> From: Geoff Huston gih@localhost
> Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI
> Cc: Roger Jorgensen rogerj@localhost, Oliver Bartels
> oliver@localhost,
>    "ipv6-wg@localhost" ipv6-wg@localhost,
>    "address-policy-wg@localhost" address-policy-wg@localhost,
>    roger@localhost
>
> At 08:13 PM 29/11/2005, Andre Oppermann wrote:
> >Salman Asadullah wrote:
> > >
> > > You seem to be far away from the ground realities.
> > >
> > > Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real
> > > issues for a good reason.
> >
> >Neither Multi6 nor SHIM6 are even in an draft RFC state yet
>
> Multi6 produced 5 WG drafts, all of which have been published as RFCs You
> can (and probably should) read through RFCs 3582, 4116, 4177, 4219, and 4218
>
> SHIM6 is working on the following drafts - again I would recommend that you
> read though all of them:...
> draft-ietf-shim6-app-refer,  draft-ietf-shim6-applicability,
> draft-ietf-shim6-arch, draft-ietf-shim6-failure-detection,
> draft-ietf-shim6-hba, draft-ietf-shim6-proto,
> and  draft-ietf-shim6-reach-detect.
>
>
> >  and to be
> >workable they'd have to be implemented on every end-host out there.
> >That is every operating system in sufficient existence.  That puts IPv6
> >even further in the already distant future considering common OS upgrade
> >and replacement cycles.
>
> yep - any form of locator / identity split is such a basic shift in the
> architectural model used by IP that changes to the stack are required. This
> is the case in mobility, nomadism, ad-hoc networking and this form of
> multi-homing. If you want agile locators and any form of persistence in
> endpoint identifiers then you are not going to get that without changes to
> the stack. Now if you are arguing that the deployed base of IPv6 is so
> large that further changes are impossible in this particular technology due
> to the inertia of the deployed IPv6 base, then that's certainly an
> interesting perspective, and not one I've heard all that often so far. If
> you are saying that this will take time to develop and deploy, then you are
> probably right, and a model that can use incremental deployment using a
> conventional initial context followed by a capability exchange to explore
> if there is mutual support for this form of communication capability, then
> you may well be onto something interesting. Although I'd hasten to add that
> this is the approach being taken within the SHIM6 architecture.
>
> >Second this doesn't solve the renumbering problem.  Renumbering is not
> >just giving hosts new IP addresses but alost managing DNS and Firewalls.
> >No even remotely workable and scaleable solution has been presented yet.
>
> I'm not sure I agree with you about the DNS and renumbering - its not a
> clearly defined space, and the implications relating to the DNS are not
> clearly understood in communication models where feasible locator sets are
> dynamically exchanged rather than always loaded into third party rendezvous
> points, as in the DNS model.
>
>
> >So nice try but no cookie.
>
> Thank you,
>
>     Geoff
>
>
>
>
>
> --__--__--
>
> Message: 8
> Date: Wed, 30 Nov 2005 01:53:49 -0800 (PST)
> From: "william(at)elan.net" william@localhost
> To: Geoff Huston gih@localhost
> cc: Randy Bush randy@localhost, Per Heldal heldal@localhost,
>         Salman Asadullah sasad@localhost, ipv6-wg@localhost,
>         address-policy-wg@localhost
> Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI
>
>
> 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@localhost
>
>
> --__--__--
>
> Message: 9
> From: Max Tulyev president@localhost
> Subject: Re: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6
> Date: Wed, 30 Nov 2005 13:33:52 +0300
>
> Hi!
>
> > > 1. No PI. _Only_ network operators get a prefix.
> >
> > I am an operator of a network - do I get a prefix ? (we have lots of
> > computers and need lots of IP addresses: currently the 5 PCs, 2
> > printers, a phone and some PDA and a server online)
> >
> > I guess you need to define the criteria in some other way. Perhaps
> > beeing registered with the national regulator
>
> I'm looking at all of that and begin to think that all this discussion about
> PI vs PA (and only [large] operators can get a prefix) is just for
> implementing some unfair rules in ISP market.
>
> Wise customers wants to have PI because of to be multihoming and have stable
> and really _provider_independent_ (i.e. not depending on upstream's faults)
> connection.
> Small operators wants to have PI because of LIR is often too expensive for
> them.
>
> Large operators do NOT want PI because of they can hold a client with their
> address space ("if you are going to change ISP - you will have a large
> trouble with renumbering your network and changing domains" or even "if you
> do not do ... - we will immediately shut down your connection"). Large
> operators (can pay for LIR) do NOT want PI because of it makes the extra
> money barrier to be an operator (LIR cost).
>
> See more on. Imagine there is no PI. If somebody really-really-really needs
> to
> be multihoming - he will be a LIR and do the LIR initial request (/20 PA for
> IPv4 instead of /24 PI he really need for years). So in this case we do not
> conserve one row of route table, but slightly loss in conserving space (/20
> instead of /24).
>
> Even more. Who is making the most noise about no PI? As I can see, large
> operators. People who have enough powerful routers to not to think about
> extra routes there.
>
> P.S. And please do not compare IP connectivity with global dynamic routing
> (it
> is a really BIG achievement of the Internet!) with PSTN and global static
> routing where switching routes to certain number plan can take several
> monthes. Of course, in PSTN we can't ever think about hot backup and upstream
> reservation (multihoming).
>
> --
> WBR,
> Max Tulyev (MT6561-RIPE, 2:463/253@localhost)
>
>
>
>
> End of ipv6-wg Digest
>