The other alternative is to listen on more sockets, one for each
interface, but that is messier to setup, in particular if you have
several addresses on each interface. (Perhaps attaching a link-id in
the scope-id field when binding the sockets, as discussed in some
other thread, ma
Brian Zill <[EMAIL PROTECTED]> writes:
> What I'm saying is that I don't see why you'd ever need to guess. It
> shouldn't matter to the user-land program how the packet got there.
> The kernel should ensure that you get a v4-mapped packet with wire
> format of IPv6 if and only if it would have le
On Fri, 28 Jul 2000, Bob Hinden wrote:
> >Is this correct usage of IPv4-mapped addresses? Or is it a violation
> >of the architecture?
after a careful reading of rfc2553 i guess it is just the correct usage.
--
Aequam memento rebus in arduis servare mentem...
Mauro Tortonesi
> On Mon, 24 Jul 2000 09:14:17 -0400,
> "Brian Haberman" <[EMAIL PROTECTED]> said:
>> According to this description, admin-local is larger than link-local
>> and smaller than site-local. Is my understanding correct? And if so,
>> is the definition really reasonable? (Although it depends
Jack,
>During w.g. last call, I suggested a change of wording in the
>definition of IPv4-mapped addresses (mail attached below). I
>see the suggestion was not incorporated in addr-arch-v3-01.
>Let me offer an example of what motivated my suggestion.
I did read and consider your suggestion. I s
hi Matt,
>> Well its not that easy. We still do not want af_inet6 listner to get
>> the connections for IPv4 if there is an af_inet listener. That is the
>> only real problem, which the socket level option fixes.
>To give a v4-specific listener priority over a v6 listener is not up
>to the API
On Fri, Jul 28, 2000 at 08:55:51AM +0900, Hideaki YOSHIFUJI wrote:
> In article <[EMAIL PROTECTED]> (at Thu, 27 Jul 2000 16:28:48
>-0500), "La Monte Henry Piggy Yarroll" <[EMAIL PROTECTED]> says:
>
> > >> the v6 application could do this more simply by binding to the v4
> > >> address (be it wil
>Ipv6 tcp layer and ipv4 tcp layer are shared.
>You cannot bind a ipv4 socket to a port already bound to ipv6 socket.
>You cannot bind a ipv6 socket to a port already bound to ipv4 socket.
>
>If you want to provide a service to ipv6 and ipv4 client through single
>local port, you must create an i
> Note that how the system picks those addresses are still not "clearly"
> specified. It may not make sense to pick all addresses
> associated with an
> interface. The reason for having multiple addresses is that
> SCTP can failover
> to another address if the primary fails. But if all the a
> To give a v4-specific listener priority over a v6 listener is not up
> to the API but the stack's PCB lookup function, yes? The only reason
> I can see for a sockopt is to allow overriding this behavior -- but
> the v6 application could do this more simply by binding to the v4
> address (be it
>> the v6 application could do this more simply by binding to the v4
>> address (be it wildcard or not) in addition to any others.
>We cannot do this with Linux.
the whole confusion of AF_INET and AF_INET6 interaction
is documented very nicely in BIND9 doc/misc/ipv6. the source
On Tue, 25 Jul 2000, Jim Bound wrote:
> >> An af_inet6 socket should not accept a connection for an af_inet socket.
> >
> >you are right. they should open another af_inet socket and fall back to
> >an ipv4 connection. however, rfc2553 does not even suggest this behaviour.
> >quoting from draft-
> Well its not that easy. We still do not want af_inet6 listner to get
> the connections for IPv4 if there is an af_inet listener. That is the
> only real problem, which the socket level option fixes.
To give a v4-specific listener priority over a v6 listener is not up
to the API but the stack'
>>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
>
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.
>> 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
^^^
I think I may have been misunderstood. Let me see if the response clears it
up?
>The discussion below raises concerns with our proposed draft for
>an SCTP sockets API. SCTP is a reliable datagram transport developed
>by SIGTRAN to carry telephony signaling information.
>One distinctive feature
Dear All:
One note to all you readers.. this draft is a very very early
first cut. We rushed it out to get it in to the drafts editor
and thus it requires quite a bit of work yet :->
I did not get Jim's original email so I have a hard time
reading the snippet below and making sense of it...
I
The discussion below raises concerns with our proposed draft for
an SCTP sockets API. SCTP is a reliable datagram transport developed
by SIGTRAN to carry telephony signaling information.
One distinctive feature of SCTP is direct support for multi-homed
hosts. SCTP has the notion of a "primary a
JINMEI Tatuya / $B?@L@C#:H(B wrote:
>
> > On Fri, 21 Jul 2000 08:46:37 -0400,
> > "Brian Haberman" <[EMAIL PROTECTED]> said:
>
> > Yes, it is equivalent to the "local scope" defined in
> > RFC 2365 and RFC 2730. It should be noted that those documents
> > refer to IPv6 scope 3
Mauro,
>> but v4 mapped does not affect the ISV porting effort at all and in fact
>> makes their job much easier if the platform they are porting to supports
>> that paradigm.
>you are absolutely right. my concern was about api issues. a modification
>in the behaviour of af_inet6 passive socket,
I think most of the items are replied in reply to Brian.
>> there's no way for the current API to recognize IPv4 traffic on top
>> of AF_INET6 socket (appears as IPv4 mapped address), and native
>> IPv6 traffic with IPv4 mapped address in the header). at least
>> we
> On Fri, 21 Jul 2000 08:46:37 -0400,
> "Brian Haberman" <[EMAIL PROTECTED]> said:
> Yes, it is equivalent to the "local scope" defined in
> RFC 2365 and RFC 2730. It should be noted that those documents
> refer to IPv6 scope 3 currently, but will need to be changed
> to scope 4.
On Sun, 23 Jul 2000 [EMAIL PROTECTED] wrote:
> do you think that every application writers can handle this complex
> checks? we at least need a guideline on "how to port your servers
> onto ipv6 without compromising security". once we go into total
> agreement i voluntee
In article <[EMAIL PROTECTED]> (at Sun, 23 Jul 2000 13:21:27 +0900),
[EMAIL PROTECTED] says:
> that briefly? i'm trying to understand your mindset, and it looks
> like as follows (correct me if i'm wrong):
> - IPv4 packet on the wire, and native-ipv4-mapped packet on the wire,
>> as i wrote in my reply to yoshfuji's email,
>> - i still think it is real serious issue
>Oh, I believe that there are many serious security issues involved with a
>number of the transition mechanisms that are either proposed or in current
>use today. And I applaud you for taking the time to l
On Fri, 21 Jul 2000, Jim Bound wrote:
> but v4 mapped does not affect the ISV porting effort at all and in fact
> makes their job much easier if the platform they are porting to supports
> that paradigm.
you are absolutely right. my concern was about api issues. a modification
in the behaviour o
Hi Itojun,
> as i wrote in my reply to yoshfuji's email,
> - i still think it is real serious issue
Oh, I believe that there are many serious security issues involved with a
number of the transition mechanisms that are either proposed or in current
use today. And I applaud you for taking the ti
>>and it was from outside, the kernel does not drop it for the sake of
>>SIIT (too-clever SIIT enabled client may try to drop it because of
>>IPv4 rules)
> Not too-clever.
i don't see any of your wording on RFC2765. i took your email as a
suggestion
In article <[EMAIL PROTECTED]> (at Sat, 22 Jul 2000 11:09:04 +0900),
[EMAIL PROTECTED] says:
> - if we got an IPv6 packet with :::127.0.0.1 in the source,
> and it was from outside, the kernel does not drop it for the sake of
> SIIT (too-clever SIIT enabled client may t
> do you say the following packet trace is the expected behavior?
> i hope you do not mean this...
in the example, please ignore "MAC address" portion.
i was making example where A and B are on the same link, and forgot
to fix the portion.
itojun
>I'm far from convinced that there is a real problem here. Your examples are
>contrived. You already agreed I was right about the first one, so let's
>look at the second again:
as i wrote in my reply to yoshfuji's email,
- i still think it is real serious issue
- i'll d
>> No, SIIT doesn't require user-level programs to receive IPv4 packets on
>> AF_INET6 socekts. It only requires that IPv6 packets (with v4-mapped
>> addresses) are received on AF_INET6 sockets. Machines living on the v6 side
>> of the translator only need to speak v6!
>Yes, SIIT is for IPv6 nod
Brian Zill wrote:
>
> Itojun,
>
> I am unwilling to give up SIIT. Changing the architecture to forbid
> IPv4-mapped addresses on the wire is unacceptable in my opinion.
Absolutely. I *hate* translators and always have done, but
unfortunately we will need them for the next ten or fifteen years.
Itojun,
>
> the point i would like to make was that:
> - it is much easier to inject malicious packet from remote,
> with bypassing normal access control imposed by normal routers
> inbetween
For the specific example you noted, use of subnet broadcast addresses in
Itojun,
I am unwilling to give up SIIT. Changing the architecture to forbid
IPv4-mapped addresses on the wire is unacceptable in my opinion.
I'm far from convinced that there is a real problem here. Your examples are
contrived. You already agreed I was right about the first one, so let's
look
>> please refer to draft-itojun-ipv6-transition-abuse-01.txt, specifically
>> section 3. my suggestion is to forbid IPv4 mapped address in the IPv6
>> headers, and remove ambiguity from the dual use.
>The implication of your recommendation is that we remove SIIT (at least
>as curr
>I am not commenting on IPv4 Mapped addresses on the wire.
>What I do or don't do with them in userland is NONE of yours or anyone
>elses business or what I do with them in my implementation. The BASE
>API and Addr Spec define them and they exist.
i too would like to see uniform API ever
> For example the problem noted in 1.1 can be addressed by simply
>making sure that known bad addresses aren't used as the destination address
>of an encapsulating IPv4 header. Itojun says that this isn't sufficient
>but I am not sure that it isn't. It is certainly true that someone can
>s
>I agree with Jim that we shouldn't break how IPv4-mapped addresses are used
>in the basic API spec, nor should we forbid their use on the wire as SIIT
>requires today.
>The security issues Itojun raises look to me to be internal
>implementation-specific issues. Let's look at his examples:
I agree with Jim that we shouldn't break how IPv4-mapped addresses are used
in the basic API spec, nor should we forbid their use on the wire as SIIT
requires today.
The security issues Itojun raises look to me to be internal
implementation-specific issues. Let's look at his examples:
> We have
All,
I just gave draft-itojun-ipv6-transition-abuse-01.txt a quick
read. It notes some legitimate problems with some of the transition
strategies. At least some of these problems can be addressed by simply
using good implementation techniques.
For example the problem noted
anyone can speak here and this is valuable.
the apis will work in 2553bis. what one does with their implementation
and how they pass ipv4 or ipv6 to the app and the apis is not anyones
business in a standards community or anywhere else. if one has an issue
with the API thats fine but not with h
On Fri, 21 Jul 2000 [EMAIL PROTECTED] wrote:
> o Do not route inbound IPv4 traffic to AF_INET6 sockets. When an
> application would like to accept IPv4 traffic, it should explicitly
> open AF_INET sockets. You may want to run two applications instead,
> one for an AF_INET socket, and anot
Hi Erik,
>> please refer to draft-itojun-ipv6-transition-abuse-01.txt, specifically
>> section 3. my suggestion is to forbid IPv4 mapped address in the IPv6
>> headers, and remove ambiguity from the dual use.
>
>Itojun,
>
>The implication of your recommendation is that we remove S
> please refer to draft-itojun-ipv6-transition-abuse-01.txt, specifically
> section 3. my suggestion is to forbid IPv4 mapped address in the IPv6
> headers, and remove ambiguity from the dual use.
Itojun,
The implication of your recommendation is that we remove SIIT (at least
Itojun,
I am not commenting on IPv4 Mapped addresses on the wire.
What I do or don't do with them in userland is NONE of yours or anyone
elses business or what I do with them in my implementation. The BASE
API and Addr Spec define them and they exist.
The only place they show up on the wire ar
Tatuya,
Yes, it is equivalent to the "local scope" defined in
RFC 2365 and RFC 2730. It should be noted that those documents
refer to IPv6 scope 3 currently, but will need to be changed
to scope 4.
Brian
JINMEI Tatuya / $B?@L@C#:H(B wrote:
>
> > On Thu, 13 Jul 2000 14:25:13 -0700,
>
>During w.g. last call, I suggested a change of wording in the
>definition of IPv4-mapped addresses (mail attached below). I
>see the suggestion was not incorporated in addr-arch-v3-01.
>Let me offer an example of what motivated my suggestion.
maybe it is too late, but I do have a comme
> On Thu, 13 Jul 2000 14:25:13 -0700,
> Bob Hinden <[EMAIL PROTECTED]> said:
>- Multicast scope name changes:
>o Changed name of scope value 1 from "node-local" to
> "interface-local"
>o Reserved scope value 3 for "subnet-local" for multi-link
> subn
During w.g. last call, I suggested a change of wording in the
definition of IPv4-mapped addresses (mail attached below). I
see the suggestion was not incorporated in addr-arch-v3-01.
Let me offer an example of what motivated my suggestion.
Suppose we have 2 IPv6/IPv4 nodes: Node A has IPv6 addr
I just submitted a new version of "IP Version 6 Addressing Architecture" to
be an internet draft. Until is available in the ID directories it can be
found at:
ftp://playground.sun.com/pub/hinden/draft-ietf-ipngwg-addr-arch-v3-01.txt
The changes in this draft resolve issues raised in the w.g
59 matches
Mail list logo
