[16NG] Re: Last Call: draft-ietf-16ng-ipv6-over-ipv6cs (IPv6 Over the IP Specific part of the Packet Convergence sublayer in 802.16 Networks) to Proposed Standard

[James Carlson <[e-mail]>]

Basavaraj Patil writes:
> On 3/14/07 11:14 AM, "ext James Carlson" <[e-mail]> 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              <[e-mail]>
Sun Microsystems / 1 Network Drive         71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]

_______________________________________________
16NG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng