>>I think it should be illegal too. Its like running telnetv4 and
>>telnetv6 on the same node. Pretty stupid IMO. But if we have a socket
>>level option to not accept v4mapped for af_inet6 it will let it happen
>>in theory (not that I believe we should).
>
>>Forget the socket level option--jus
> Forget the socket level option--just adopt the SCTP solution in
> general. If you are going to allow binding to subsets of addresses
> you might as well make it completely general.
Allowing bind() to subsets of addresses does not necessarily mean that such
option is of no use. A SCTP app may
> Blech! In SCTP we need to allow binding on arbitrary subsets of
> addresses. Our solution is to allow multiple calls to bind(). There
> is nothing special about the sets "all IPv4 addresses" and "all IPv6
> addresses" (well, there shouldn't be...).
This is a point which is not clear in the c
>> - change RFC2553 API to disable RFC2553-inbound
>> PROS: applications gets simplified very well, AF_INET6 is
>> always IPv6, AF_INET is always IPv4 (good for security)
>> PROS: RFC2553-inbound case is gone, application writers do not
>>
> - change RFC2553 API to disable RFC2553-inbound
> PROS: applications gets simplified very well, AF_INET6 is
> always IPv6, AF_INET is always IPv4 (good for security)
> PROS: RFC2553-inbound case is gone, application writers do not
>
Alex
Alex Conta wrote:
>
> Thank you for your note Vlad.
>
> The interpretation of the RFC 2473 should be done in the context of RFC 2460. Two
> pieces of text are perhaps more important than others:
>
> RFC 2473
> "Tunnel Encapsulation Limit options are of interest only to tunnel
>entry
Thank you for your note Vlad.
The interpretation of the RFC 2473 should be done in the context of RFC 2460. Two
pieces of text are perhaps more important than others:
RFC 2473
"Tunnel Encapsulation Limit options are of interest only to tunnel
entry points. A tunnel entry-point node is requi
On Tue, 25 Jul 2000 14:00:35 -0400 Jim Bound <[EMAIL PROTECTED]> wrote:
>Great. See my last mail to Mauro too just sent I go into more detail on
>the principle (or is that principal :))
I didn't see it on either of the lists. I'm still interested in your
definitions to see if I understand.
Hello
After discussing this with a colleague who is trying to implement this spec
I believe there may be a problem with defining Tunnel Encapsulation Limit Option
as a Destination Option. When the packet is fragmented, the destination option
header can be placed in the fragment if no routing hea
>> This is a good idea and why I believe a hybrid stack is far superior
>> to a pure dual stack implementation. This paradigm is also inline
>> with the IPv6 deployment message which is IPv4/IPv6 Integration not
>> Migration. So I am real happy to hear SCTP is thinking that way
>> too.
>
>Good.
Hi Mauro,
hey your bringing out important stuff here that needs to be understood.
thanks...it is just so busy before an ietf meeting on the lists...
>> >you are absolutely right. my concern was about api issues. a modification
>> >in the behaviour of af_inet6 passive socket, so that they are not
Jim Bound <[EMAIL PROTECTED]> writes:
>I think I may have been misunderstood. Let me see if the response clears it
>up?
...
>[piggy wrote:]
>> The issue is that a single host may have both IPv4 AND IPv6
>> interfaces. SCTP allows a single association (connection) to span
>> both kinds of interfa
On Mon, 24 Jul 2000, Jim Bound wrote:
> >you are absolutely right. my concern was about api issues. a modification
> >in the behaviour of af_inet6 passive socket, so that they are not allowed
> >to accept connections from af_inet sockets, would have imho nightmarish
^^^
14 matches
Mail list logo
