Does anybody know of anything (RFC, implementation, idea etc)about
converting IPv4 packets to IPv6 packets ?
This could be usefull for older stations (most currently working windows)
that would like to connect to IPv6 only servers.
(Do such servers exist ?)
Yuval
___
> I believe you can make your set of rules simpler if you introduce
> a new lifetime (or condition if one needs something smarter than
> a delay). I'll call it "regen lifetime" and when the regen lifetime
> of an anonymous address expires then a new address is created, checked
> by DAD then is use
>3) When multicast addresses are stored in a sockaddr_in6,
> how is the
>scope id field Interpreted?
>
> => I believe it should be an interface index because it is the way
> it works today (or before scope id introduction if you prefer :-):
> IPV6_MULTICAST_IF & IPV6_JOIN_GROUP deal with
Rich,
>
> My assumption was that recvfrom() and accept() should return sin6_flowinfo
> from the received packet, and connect() and sendto() should take
> sin6_flowinfo and put it into sent packets.
>
> For bind(), I'd say either error if sin6_flowinfo is non-zero, or ignore
> sin6_flowinfo.
My assumption was that recvfrom() and accept() should return sin6_flowinfo
from the received packet, and connect() and sendto() should take
sin6_flowinfo and put it into sent packets.
For bind(), I'd say either error if sin6_flowinfo is non-zero, or ignore
sin6_flowinfo.
Rich
> -Original Me
> > outbound: apply policy and IPSEC to the error packed based on the
> > header of the received packet (except the src/dst swapped as if the
> > packet were going out)
>
> > inbound: the policy check on ICMP error packets is based on the
> > contained header (not the outer ICMP). Thus
>> > unrecognized value was found after decompressing a packet, the returned
>> ^you mean decrypting?
>> > packet is the decompressed packet (if the security rules allow it to be
>> > sent at all).
>I did mean decompressing. I thought someone broug
>> >The conclusion: sin6_flowinfo mbz in recvfrom(), and may contain
>> >only class bits in sendto(). It is much more convenient to make with
>> >setsockopt() or ancillary data.
>My take it also that accept() should behave the same as recvfrom,
>since a native application might take the address r
At 8:34 AM +0900 6/21/00, JINMEI Tatuya wrote:
> > Steve Deering <[EMAIL PROTECTED]> said:
> > If the
> > unrecognized value was found after decompressing a packet, the returned
> ^you mean decrypting?
> > packet is the decompressed packet (if th
hello,
>> (6) what is the endian of sin6_flowinfo?
>> I guess it is network byte order, since it appears on the wire.
>Doesn't the basic API say that everything is in network byte order?
>There used to be some macros to take apart the flowinfo into a tclass
>and a flowla
> >The conclusion: sin6_flowinfo mbz in recvfrom(), and may contain
> >only class bits in sendto(). It is much more convenient to make with
> >setsockopt() or ancillary data.
My take it also that accept() should behave the same as recvfrom,
since a native application might take the address retur
> more questions (I could not find answer from my archive):
> (4) what happens if we connect(2) with sin6_flowinfo filled?
> my guess is that sin6_flowinfo sticks into pcb, and
> will be attached to every packet we will send.
My assumption is the same as y
> On Thu, 15 Jun 2000 15:03:09 -0700,
> Steve Deering <[EMAIL PROTECTED]> said:
> Thus, if the unrecognized value is in a header following a Fragment header,
> then the returned packet is the reassembled packet (or as much of the
> reassembled packet as will fit, if the whole packet does
> On Thu, 15 Jun 2000 23:21:13 +0300 (EET DST),
> Markku Savela <[EMAIL PROTECTED]> said:
> This is what I have been thinking that would make sense. At least in
> IPv6 ICMP, the error messages are clearly distingquished. So I have
> been wondering if it would be a good rule as follows:
14 matches
Mail list logo
