About RIPE | Contact  | Search | Sitemap    
Homepage RIPE  
RIPE Community Mail Archives
search  
     
RIPE Navigation Ends
About RIPE Maillists
Maillists Archive
Global Lists
Non Active Lists
RIPE NCC Navigation Ends
Next Section

[address-policy-wg] unsubscribe jkuijer@dds.nl

  • From:
  • Date: Tue, 29 Nov 2005 12:25:59 +0100

Citeren address-policy-wg-request@localhost:

> Send address-policy-wg mailing list submissions to
> 	address-policy-wg@localhost
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://www.ripe.net/mailman/listinfo/address-policy-wg
> or, via email, send a message with subject or body 'help' to
> 	address-policy-wg-request@localhost
>
> You can reach the person managing the list at
> 	address-policy-wg-admin@localhost
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of address-policy-wg digest..."
>
>
> Today's Topics:
>
>    1. Re: Re: [ipv6-wg] IPv6 PI (Randy Bush)
>    2. Re: Re: [ipv6-wg] IPv6 PI (Andre Oppermann)
>
> --__--__--
>
> Message: 1
> 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: 2
> 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 address-policy-wg Digest
>





 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | Copyright Statement
RIPE.NET Homepage LIR Portal RIPE Community