Re: chicago IETF IPv6 connectivity

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jun-ichiro itojun Hagino wrote:
>>> 	i guess we are living with very different assumptions.
>>>   
>>>       
>> it's just that the needs of applications vary as widely as the needs of
>> users.  it's not as if all Internet users do nothing but email and the
>> web, and neither is it as if all Internet applications are like HTTP or ssh.
>>     
>
> 	if you are not under NDA, could you please be more specific?  source
> 	code, RFC/draft for the protocol, whatever?  i'm getting tired of this
> 	guessing games.
>   
what do you want me to do, describe in detail every distributed
application that I've ever worked with?  I'm not talking about any
specific application, I'm generalizing from several applications that
I've worked with and/or am otherwise familiar with.
> 	once you run ALG (which i guess you do not like) IPv6-to-IPv4 or IPv4-to-
> 	IPv6 looks much like SMTP relaying.
true.  ALGs are okay for applications that have explicit intermediaries,
like SMTP.   I don't like ALGs so much when they're used as interception
proxies.  sometimes they work okay, sometimes not.

> 	do not underestimate my paranoid-ness, i'm an OpenBSD developer
somehow, I think this should be on a t-shirt,  or a bumper sticker.  :)

[analysis of the many layers that could potentially modify traffic omitted]

agree with all of those.  but it sounds like you're close to arguing
that because there are so many other things that can screw with DNS,
it's okay for getaddrinfo() to return bogus results too.

in general, things that alter or spoof network traffic are evil.  they
are evil whether the traffic being altered or spoofed is IP, TCP, UDP,
DNS, or a higher-layer protocol; they are evil whether the altering or
spoofing is being done "on the wire" (by modifying packets) or at the
API level.   all of those things make it more difficult for applications
to get consistent, repeatable behavior out of the network.

>>>> 	what is the problem you have with "multiple-addresses-per-host" problem?
>>>> 	i never had any problem even with IPv4.
>>>>     
>>>>         
>> it's the fact that in IPv6 if you don't select the best source and
>> destination address to talk to a node, you might either fail to get a
>> connection (and have to wait a long time for a timeout), or you might
>> get a connection that performs much worse than some other
>> source/destination address pair you could have used.  this was true for
>> IPv4 nodes with multiple interfaces also, but this was mostly solved in
>> IPv4 by not having multiple active network interfaces.  (people tried
>> it, it didn't work well, so they stopped doing it.)  In IPv6 the normal
>> situation for hosts on multihomed networks is to have multiple
>> addresses, and there are several pressures to have additional addresses
>> - like for mobility, or using ULIAs for local apps on enterprise
>> networks so that they won't be affected by renumbering.  so address
>> selection becomes more important in IPv6 than it was in IPv4.
>>     
>
> 	ok, so you are basically worried about uRPF, performance difference,
> 	and/or firewalling policy differences when you have multiple exit links.
>
> 	do not take it as a self-promotion, but my take on this is in RFC3178.
>   
it's not just multiple exit links, it's having multiple addresses per
host for any number of reasons.  (mobility, renumbering, the desire to
have stable local addresses, and also the possibility of multiple active
network interfaces)

but things like RFC 3178 do help.  if we can get back to the expectation
that one address per host is the normal case, we'll make life much
simpler for application writers.
> 	so i can solve problem for Skype, so i guess i can solve problem for
> 	your "distributed computation system".  want to hire a consultant? :-P
>   
I can solve it too, and have done so on a couple of occasions.  but I
don't pretend that it's easy to retro-fit every existing distributed
application (or to build every new distributed application) to handle
multiple realms.  NATs have drastically raised the burden on
applications by dividing the Internet up into multiple address realms;
similarly, IPv4/IPv6 coexistence also divides the Internet up into
multiple address realms.  Thus a "mixed" IPv4/IPv6 network is almost as
dysfunctional as a NATted IPv4 network.

Keith


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]