[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: v4 side unmodifiable
My experience on this is that if the content provider setup its own Teredo
and 6to4 relays, then users will have no troubles.
So again, no need to modify the IPv4 stack on that service provider network.
Of course, there will be ALWAYS users with problems, but this is the corner
case due to missconfiguration of the users network. For example, the network
adminstrator decides to announce an IPv6 prefix with RA or DHCPv6, but has
no IPv6 connectivity to outside. Then the hosts in that network will not try
6to4 or Teredo (because they believe they have already native IPv6
connectivity), and will fail. This kind of situations are unavoidable and
not due to IPv6 or anything that we do, is just a problem of BAD networks
administrators, not doing correctly their job :-( Same can happen with a bad
IPv4 network configuration, even if IPv6 is not involved !
Regards,
Jordi
> De: Brian Dickson <briand@ca.afilias.info>
> Responder a: <owner-v6ops@ops.ietf.org>
> Fecha: Thu, 06 Dec 2007 20:12:55 -0800
> Para: <jordi.palet@consulintel.es>
> CC: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
> Asunto: Re: v4 side unmodifiable
>
> JORDI PALET MARTINEZ wrote:
>> I don't think is a good idea to modify IPv4. It is the same difficulty than
>> having IPv6 in those boxes where the manufacturers aren't longer in the
>> market, they have no spare memory, or whatever.
>>
>> And I believe is not good to make a difference between what is a server and
>> a client from this perspective. May be need to look into concrete examples,
>> but it is looking already for a solution too early ?
>>
>>
> I think that, in order to ensure we find the solutions which can be
> deployed (easily, quickly, cheaply, etc.),
> we need to identify three things:
> - what can be done (on an element-by-element basis)
> - what the required elements of a specific solution involve
> - what the specific corner cases are in the problem space.
>
> Here is an example of the problem space having a corner case:
> If a content provider (who operates farms of servers, where the servers
> are commodity, new, and open source),
> wants to provide content to IPv6-only sites, there is a real problem.
>
> Even if the provider has IPv6 transit and a dual-stack infrastructure,
> there is a problem.
>
> If the provider adds AAAA records, it can trigger a bad user experience
> from unintended sources (e.g. toredo hosts).
> These are not within the control of the content provider. The content
> provider is limited to solutions within its control.
>
> So, that provider may actually *want* to have solutions from our
> solution space as options, and is likely willing to make
> changes on the v4 *server* host to accomplish this.
>
> It is an exception, of course, but a very important one for
> consideration, as the uptake of IPv6 depends on content being available,
> at no worse a quality of user experience as under IPv4 (for the same sites).
>
> Brian Dickson
>> We should really focus in trying to make it in the hosts that are have an
>> IPv6 stack.
>>
>> Regards,
>> Jordi
>>
>>
>>
>>
>>
>>> De: Iljitsch van Beijnum <iljitsch@muada.com>
>>> Responder a: <owner-v6ops@ops.ietf.org>
>>> Fecha: Thu, 6 Dec 2007 17:31:54 -0800
>>> Para: IPv6 Operations <v6ops@ops.ietf.org>
>>> Asunto: v4 side unmodifiable
>>>
>>> Jari basically said this ^^
>>>
>>> However, although I agree it's true in the general case, I think for
>>> non-trivial servers/services, this isn't true: if there is a good
>>> reason to make changes on the IPv4-only side, it may be possible to
>>> make them.
>>>
>>>
>
>
**********************************************
The IPv6 Portal: http://www.ipv6tf.org
Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.