Messages | Bytes| Who
+--++--+
10.34% |3 | 14.09% |18730 | [EMAIL PROTECTED]
10.34% |3 | 13.09% |17410 | [EMAIL PROTECTED]
10.34% |3 | 12.26% |16302 | [EMAIL PROTECTED]
6.90% |2 | 8.16% |108
SCTP API should be done in that spec and be congruent to 3493 and new
addendum APIs which we need for getnameinfo. I believe Jack McCann is
contacting Itojun to work on addendum API spec for getnameinfo.
/jim
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
>
Don't remove deering just the contact information.
Thanks
/jim
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Jun-ichiro itojun Hagino
> Sent: Monday, December 15, 2003 2:30 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: comments
I support this nice concise report. Esp. that multicast is well defined
and I agree. IPv4 Mapped "on the wire" should not be permitted ok as API
for 3493. Kill NSAPs they are dead and gone. ACK on compatible address
too.
Thanks
/jim
> -Original Message-
> From: [EMAIL PROTECTED] [mailt
More generally, I still don't see why there is a restriction on the
prefix length for all IPv6 unicast addresses where the first 3 MSBs are
other than 000. I could understand the wording in RFC 3513 (and RFC
3513bis) if the restriction was intended for "unicast addresses that are
configured via sta
I would suggest reading RFC 3627.
Regards,
Brian
Stephen Sprunk wrote:
Thus spake "Barany, Pete" <[EMAIL PROTECTED]>
... RFC 3513 ... Section 2.5.1:
-
"For all unicast addresses, except those that start with binary value
000, Interface IDs are required to be 64 bits long and to be constructe
Thus spake "Barany, Pete" <[EMAIL PROTECTED]>
> ... RFC 3513 ... Section 2.5.1:
> -
> "For all unicast addresses, except those that start with binary value
> 000, Interface IDs are required to be 64 bits long and to be constructed
> in Modified EUI-64 format."
>
> ... RFC 2526 ... Section 2:
>
