Re: [TCLCORE] TIP #162 IPv6 support

[rafael M. <raf...@no...>]

On Thu, 25 Mar 2004, Donal K. Fellows wrote:

>
> The problem with datagram protocols (of any kind) is that they don't fit
> well with the stream-oriented paradigm of Tcl channels.  While you can
> hack it around to make it work, it's a bit of a talking dog.

That explains my headache on hacking TCL/IPv6...

> (But
> anything stream-oriented should be able to fit under a channel without
> any problems.)
>

If I'm not wrong, as traditional TCL model (Channel) does not cover
datagram protocol, Stuart's strategy seems to introduce a new model:

"Control end point" -> CEP

not to overlap the Channel-Socket model...

Taking a overall look, it seems a good work,  and the signature problem is
solved in a natural way.
Two new flags are introduced:

?-type type?       # You cannot integrate in the traditional channel model
?-domain domain?   # the same "-family" flag I proposed.


> > * Multihoming enabled: The current implementation only saves the
> > pointer to one addresses, instead a list of linked
> > addresses...(struct addrinfo). This may originate DNS resolution
> > problems while transition into IPv6...
>
> Not an issue I understand enough to comment on.
>
OK. Very easy.  Let's try to explain:

- Suppose actual TCL socket system TCP/IPv4.
You are programming a MUA , trying to access the SMTP server:
mail.server.com: This server has two IP's interfaces: 213.56.125.3
for the public Internet, and 10.0.0.3 for the Intranet.  Your
firewall/router at 10.0.0.1 cuts
off  all the ports but those of HTTP and FTP. From the Intranet, your
TCL
programmed MUA, tries  to solve the address mail.server.com and it gets
"213.56.125.3". As the firewall does reject your request, you get
"connection error" as it the remote server were down. However if you type
de dot address "10.0.0.3" instead of mail.server.com , you will get
connected as expected.

Multihoming, implemented at C API (gethostbyname(),getaddrinfo()), but
wasted by actual TCL
implementation, would allow you to try alternate resolutions at "socket"
TCL call, as the DNS
returns you a list ok list of linked addresses
("213.56.125.3","146.56.145.2","10.0.0.3").

Now , the IPv6 transition may make it harder. Full transition
will take some
years, and meanwhile, on the first times , most clients will have no IPv6
connectivity, but
DNS running on IPv4 WILL SOLVE to IPv6 addresses (now they are), even
preferently to those on IPv4:

I.e

mail.server.com ->

("2003:546a:e474:3bf::10","213.56.125.3","146.56.145.2","10.0.0.3")

Some versions ago, this was a detected bug on a famous browser...


I think Stuart's strategy  is missing this point . Not sure,I have to
check more deepthly. Ready  to colaborate ?

> > * Should we enable a new flag to filter the DNS search ?
> > "-family"....
>

Stuart calls it "-domain".

> I'd have thought that the addressing family would be implicit in the
> protocol type.

But protocol type does not imply the family...

You can have UDP-IPv6 , UCP-IPv4, TCP-IPv6, TCP-IPv4...

> Separating that would add a lot of complexity for no
> gain to the 99.99% (add extra 9's to taste) of Tcl users who don't want
> it.  Let's try to keep common stuff easy.
>

I do agree. TCL is not designed to make fine networking....


> The other issue with that statement is the assumption that name
> resolution is done by DNS.  That's not universally true, alas.
>

Well, resolution on /etc/hosts is dealed on an abstract way on
gethostbyname(), getaddrinfo()...which are standing on TCL implementation.


> Donal.
>

Cheeers.

Rafa.