Basavaraj Patil writes: > On 3/14/07 11:14 AM, "ext James Carlson" <[EMAIL PROTECTED]> wrote: > > That issue is the exclusive use of IPv4 or IPv6 on Packet CS. Why > > must it be exclusive? The first four bits of the datagram tell you > > conclusively whether you're looking at IPv4 or IPv6, so why is strict > > segregation needed? > > Not sure I understand what you mean by segregation... The same packet CS is > used for IPv4 as well as IPv6. There are no separate CS' per se. > The classification rules segregate an IPv4 packet from an IPv6 packet and > map it to the appropriate transport connection (CID) over the air interface.
That's not what I meant. A single CID using just Packet CS could handle both IPv4 and IPv6 traffic on the same interface. You'd do this (on the receiver side) by looking at the first four bits of the inbound IP datagram. They're '4', then it's IPv4. If they're '6', then it's IPv6. If it's anything else, discard. I'm noting that you don't need to make a given Packet CS instance exclusively IPv4 or IPv6, and I'm asking why this wasn't discussed. Is it because segregation by way of CID is seen as being a superior mechanism? If so, that's fine, but I think it'd be good to document. > > Can't both run on the same link? > > I guess you mean both IPv4 and IPv6 packets on the same transport connection > (CID), right? Yes. > Why would you want to do that even if you could? Because it's simple ... ? > It is cleaner > to setup separate transport connections and use specific classifiers for > each of these which gives you more control over the type of QoS or bearer > for each. That's interesting. Would one expect IPv4 and IPv6 to get different QoS treatment? > But to answer your question more specifically: > No. When the transport connection is established there is a parameter which > specifies the CS that the connection will use and it is specified in Sec > 11.13.19.1 of IEEE P802.16-REVd/D5-2004. The options in the table indicate > that the connection will support only IPv4 (1) or IPv6 (2) etc. Right; I'm asking why it's being done that way. (Or, more specifically, why there doesn't seem to have been any discussion. Perhaps the discussion was held at the IEEE?) > > (I'm also a bit concerned that this proposal will end up rediscovering > > RFC 1547 over time, as other unnegotiated point-to-point mechanisms > > have in the past, and the reasons why PPP's negotiation exists. I'm > > certainly not arguing for the use of PPP over Ethernet CS -- that'd be > > worse still -- but I think the IEEE may have made a mistake in > > defining an IP Packet CS rather than a PPP Packet CS.) > > IEEE is specifying what is called as GPCS (generic packet CS) and I think > that some of these will be addressed therein. OK. In that case, my concern would be for interoperability. Having three or four ways to do something is much worse than having one. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
