Hi Walter.
The L2TP MIB we have today, which for the record is the MIB for RFC2661 L2TP over IPv4, has available for extensive review by this group as well as the MIB Doctors whose time is not easy to come by and blessing sometimes difficult to achieve. It has been a long and tedious process that I would hate to turn on its ear at this point and try to repeat from square zero. As you have mentioned, L2TPv3 will require significant MIB changes in order to support multiple L2 transports. This is a reasonable opportunity to ensure that the MIB is fully "IPv6 ready," particularly in as much as this affects usage of the base tunnel MIB cited in this thread. I think the WG would be pleased to have your MIB expertise available for this effort. So, unless your objections today are so strong that you think that the current MIB is completely *broken* for RFC2661-based L2TP tunneling of PPP over IPv4, then let's go ahead and move forward with what we have now, and then begin anew for L2TPv3 with fresh insights. Thanks, - Mark Klausberger Walter wrote: > > Hi, > > I think the Tunnel MIB was fine, when it was defined, but I do not think > that it was a very good idea to use it as base for L2TP. Maybe you could do > a fast adaptation by changing TOS to traffic class and the like, but don't > we need additional enhancements in the near future. The tunnel MIB is fixed > to IPv4. > > I had some discussion with Evan Caves and Dave Thaler during the San Diego > meeting a year ago. This MIB fits for all kind of statically used tunnels > over IPv4, but I found a lot of problems together with dynamically created > tunnels (in LAC case via RADIUS) and L2TP over ATM/Frame Relay (e.g. > endpoint identifier, security,...). > > Now we have this new case with IPv6. Next may be MPLS or something else. > Shouldn't we consider an alternativ to the Tunnel MIB as part of a new MIB > for L2TP, which is still no RFC (I wonder if it will ever become an RFC)? Or > should we think of an advanced version of a more generic Tunnel MIB. > > Or should we make a seperate MIB for L2TP over IPv6? (then we should do be > more flexible than the Tunnel MIB)? > > Hope you think not I'm a radical, but this issue concerns me for more than a > year now and so IPv6 is just a new trigger. I hoped that we could fix all > the problems with a new MIB for L2TPv3... > > regards > - walter > > > -----Original Message----- > > From: Daniel Feldman [mailto:[EMAIL PROTECTED]] > > Sent: Saturday, December 08, 2001 7:12 AM > > To: W. Mark Townsley > > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: RE: [L2tpext] IP Tunnel MIB > > > > > > Sorry, I wasn't on the L2TPext list back in March... > > > > The minimal modification that RFC2667 should suffer in order > > to be IPv6 > > compatible would be, of coarse, having the IP address fields changed > > from 32 to 128 bits. Another possible change would be > > including the Flow > > Label field to the TunnelIfEntry (it includes now LocalAddress, > > RemoteAddress, EncapsMethod, HopLimit, Security and TOS). TOS can be > > used as traffic class, so just a name change there. > > > > -----Original Message----- > > From: W. Mark Townsley [mailto:[EMAIL PROTECTED]] > > Sent: Saturday, December 08, 2001 2:45 AM > > To: Daniel Feldman > > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: Re: [L2tpext] IP Tunnel MIB > > > > > > > > > > Daniel Feldman wrote: > > > > > > Dear IPNG and L2TP groups, > > > RFC 2667 deals with IP Tunnel MIB, which is needed for the > > L2TP > > > MIB. However, it only supports IPv4: > > > > > > "Finally, this MIB does not support tunnels over non-IPv4 networks > > > (including IPv6 networks). Management of such tunnels may be > > supported > > > by other MIBs." > > > > > > Is there any work on such an MIB? > > > > Not that I know of. > > > > > It is required for having L2TP > > > over IPv6... > > > > I pinged the list back in March about L2TP over IPv6 and received > > nothing but > > deafening silence. I would hope that any changes in the MIB to support > > L2TP over > > IPv6 would be very, very, minimal. > > > > > > > > Thanks in advance, > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > Daniel Feldman > > > System Engineer, IC4IC Ltd. > > > office: +972(4)959-4644 ext. 121 > > > mobile: +972(55)990-299 > > > fax: +972(4)959-4944 > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to [EMAIL PROTECTED] > > > -------------------------------------------------------------------- > > > > > > _______________________________________________ > > > L2tpext mailing list > > > [EMAIL PROTECTED] > > > https://www1.ietf.org/mailman/listinfo/l2tpext > > > > _______________________________________________ > > L2tpext mailing list > > [EMAIL PROTECTED] > > https://www1.ietf.org/mailman/listinfo/l2tpext > > > > _______________________________________________ > L2tpext mailing list > [EMAIL PROTECTED] > https://www1.ietf.org/mailman/listinfo/l2tpext -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
