headers
Prakash Easwar | 1 May 2002 17:39

question on multilink ppp mibs

hi all,

RFC 1990 doesnot specify the relationship of the multilink ppp module
with
MIB II ifTable. Do we need to add an entry/s in the ifTable for
multilink.

Also I was not able to find any mibs associated with multilink ppp. Are
there any mibs defined, standard or otherwise, to manage the multilink
ppp layer. Should we be using
the existing ppp mibs do manage the multilink ppp layer.

thanks in advance
prakash
Permalink | Reply | 1 comment |
headers
Michael MacFaden | 1 May 2002 20:27

Re: question on multilink ppp mibs

On Wed, May 01, 2002 at 11:39:46AM -0400, Prakash Easwar wrote:
>RFC 1990 doesnot specify the relationship of the multilink ppp module
>with MIB II ifTable. Do we need to add an entry/s in the ifTable for
>multilink.

I chose the following approach...
http://www.nanog.org/mtg-0102/ppt/mibs/sld070.htm

>Also I was not able to find any mibs associated with multilink ppp. Are
>there any mibs defined, standard or otherwise, to manage the multilink
>ppp layer. Should we be using the existing ppp mibs do manage the multilink ppp layer.

You might be able to find something at http://www.mibcentral.com

Other than performance stats, we chose to just use cli for config settings:

rs(config)# ppp set ? 
 mlp-encaps-format        - Set MLP encapsulation format(Default: long format)
 mlp-frag-size            - Set size of the mlp frames under which no 
                            fragmentation is needed(Default: 1500 Bytes)
 mlp-fragq-depth          - Set the depth of mlp fragment q(default is 1000).  
 mlp-orderq-depth         - Set the depth of mlp order q(default is 1001).

Regards,
Mike MacFaden
Permalink | Reply | 0 comments |
headers
Cain Brian-BCAIN1 | 1 May 2002 21:37

Nits for pppext-eap-ttls-01

Nits for pppext-eap-ttls-01:

Section 6.4: "Thus phase 2 of a resumed session proceeds just it would a new session...", probably should be
"Thus phase 2 of a resumed session proceeds just as it would for a new session..."

Section 7: "The constant string 'key expansion' is used as input ...", and "... with the constant string set
to 'ttls keying material', as follows: ..."  

The strings referred to are ASCII-encoded character strings?  Shouldn't that be more explicit?

Section 9: "Also, the representation of the Data field of an AVP in EAP-TTLS is identical to that of
Diameter."  Not quite.  The 'P' bit is missing.  Was this an intentional omission or did it just fall out of
sync?  If it were intentional, it should probably be noted as such.  What's the reason that there cannot
simply be a pointer to the Diameter draft's representation (if they're supposed to be identical anyways...)?

--
Brian Cain
Permalink | Reply | 1 comment |
headers
Anil Kumar Reddy | 2 May 2002 18:49
Picon

Question on RFC-2472: IPv6 over PPP

Hi,

    I have a question about RFC-2472 (IPv6 over PPP), related to
    interface identifier option. Could somebody please answer.

    RFC-2472 gives 3 options in selecting an interface identifier for
    the negotiation. My doubt is related to option #1 - creating it from
    EUI-64 or EUI-48 identifiers. It says the 'u' (universal/local) bit
    should be set to 1, while derriving the interface identifier from
    EUI-48 identifier.

    In this scenario, suppose we create a ppp interface (which is a logical
    interface) with an interface address derrived from the above EUI-48
    ('u' bit set to 1), extracted from any locally available interfaces.
    Then there is a chance of address clashing, when we want to configure
    the interface (physical), from which we have taken EUI-48 identifier &
    used for ppp interface. And it will not be possible to have two
interfaces
    with the same address (& globally unique - u bit).

    What is the meaning of these statements in RFC-2472 ??

    Thanks in advance for your help.

Regards,
Anil
Permalink | Reply | 0 comments |
headers
Karl Fox | 6 May 2002 22:18
Picon
Favicon

No PPPEXT meeting at Yokohama

Dear PPP aficionados,

There will be no meeting of PPPEXT at Yokohama because
1) I'm trying to keep a lid on new work items, and
2) I'd have to pay my own way.

Sorry,

Karl
Permalink | Reply | 0 comments |
headers
HOULLIER Francis FTRD/DMI/CAE | 7 May 2002 17:28

Multiplexing of IP datagrams with the same ToS field in the same PPPmux frame.

Hi,
In case of carrying IP datagrams over PPP Mux frames, is it possible to multiplex frames containing the same ToS field ?

Thanks.

Permalink | Reply | 1 comment |
headers
James Carlson | 7 May 2002 17:40
Picon

Re: Multiplexing of IP datagrams with the same ToS field in the same PPPmux frame.

HOULLIER Francis FTRD/DMI/CAE writes:
> <BR><FONT SIZE=2 FACE="Arial">In case of carrying IP datagrams over PPP Mux frames, is it possible to
multiplex frames containing the same ToS field ?</FONT></P>

Yes.  You can basically multiplex anything you care to.  It's not set
by a standard.  The only thing that it says is this:

   Implementers may choose additionally to implement using timers.  In
   such a case a timeout in addition to the conditions stated above is
   used as a stopping criteria of the multiplexing process.  Moreover,
   it may be desirable to limit the maximum size of a multiplexed packet
   to be considerably smaller than MRU for reasons of multiplexing
   latency and packet error considerations.

In other words, if you have reasons to avoid multiplexing certain
frames, then by all means, feel free to do so.  The sender is not
obligated to multiplex anything.

By the way: please don't send HTML to mailing lists.

--

-- 
James Carlson, Solaris Networking         <james.d.carlson <at> east.sun.com>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677
Permalink | Reply | 0 comments |
headers
Bill Whelan | 14 May 2002 23:05

Question about RFC 2716 (PPP EAP TLS Authentication Protocol)

I have a question regarding one of the examples in section 3.8.  On pages
12-13 there is an example of a client failing to authenticate to the server.
The fifth message from the authenticator shows (TLS change_cipher_spec, TLS
finished) which indicates (to me at least) a successful client
authentication.  Subsequently, the TLS Alert message seems to be generated
spontaneously.

The text of section 3.1 in the first three paragraphs of page 5 seeems to
indicate the (TLS change_cipher_spec, TLS finished) is NOT sent when the
client fails to authenticate.

Any chance there's a cut-and-paste error in the example?

By the same token, might the same problem exist in the following example of
server authentication failure on pages 13-14?  Isn't the Authenticating
Peer's message containing only (TLS change_cipher_spec, TLS finished)
extraneous?  The previous message from the Authenticating Peer also
contained the TLS finished.

Thanks,
Bill Whelan
Permalink | Reply | 0 comments |
headers
Daniel Feldman | 15 May 2002 09:06

RE: [L2tpext] Please Review our Algorithm for Auto Detection

        Hi Nurit,
        nice to hear from you again.
        I would say this algorithm may work, only in case you are COMPLETELY sure that you cannot receive other packets such as XXX over ATM.

        I would say that in the generic case you don't have to differentiate between VC-Mux and LLC encapsulated packets, since in the case of VC-Mux you have to choose a priori the protocol running over ATM. In fact, if you take a look at RFC2515, you can see that part of the definition of the VCC is the kind of encapsulation...

        Regards,
                Daniel Feldman

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daniel Feldman
System Architecture Team Leader, IC4IC Ltd.
office:   +972(4)959-4644 ext. 121
mobile: +972(55)99-0299
fax:      +972(4)959-4944
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


-----Original Message-----
From: Nurit Sprecher [mailto:nurit.sprecher <at> SeabridgeNetworks.com]
Sent: Tuesday, May 14, 2002 12:23 PM
To: 'PPPoE Mailing List (E-mail)'; 'L2tp (E-mail)'; 'jh <at> telia.fi';
'dan <at> dma.isg.mot.com'; 'ietf-ppp <at> merit.edu'; 'Manuel Stol'
Subject: [L2tpext] Please Review our Algorithm for Auto Detection


My product works in an environment through which I expect  to receive only
PPPoA or PPPoE over ATM packets. The AAL5 encapsulation format of the
packets may be either VC Mux or LLC.

Thus, the packets can be one of the following:
*       PPP over ATM using AAL5 VC Mux encapsulation format.
*       PPP over ATM using AAL5 LLC encapsulation format.
*       PPPoE over ATM using AAL5 VC Mux encapsulation format.
*       PPPoE over ATM using AAL5 LLC encapsulation format.

I would like to perform auto detection between these possible packets,
according to the following algorithm. I’ll appreciate if you can review it
and confirm me that it is working, and I did not miss any point.

The Algorithm for auto detection:

The first word of the packet should be inspected:
*       If the first word is 0xAAAA, then the packet is PPPoE over ATM using
AAL5 LLC encapsulation format.
*       If the first word is 0x0000, then the packet is PPPoE over ATM using
AAL5 VC Mux encapsulation format.
*       If the first word is 0xFEFE, then the packet is PPP over ATM using
AAL5 LLC encapsulation format.
*       If the first word is other than the three option appearing above,
then the packet is PPP over ATM using AAL5 VC Mux encapsulation format, and
the first word is actually the PPP protocol ID, which its values are defined
by IANA and attached below. As we can see, there is no conflict between the
three values above and the protocol ID possible values.

Thanks in advance, Nurit.

Assigned PPP DLL Protocol Numbers

Value (in hex)  Protocol Name                       Reference
--------------  ----------------------------------  ---------
0001            Padding Protocol
0003            ROHC small-CID                      [RFC3095]
0005            ROHC large-CID                      [RFC3095]
0007 to 001f    reserved (transparency inefficient)
0021            Internet Protocol version 4
0023            OSI Network Layer
0025            Xerox NS IDP
0027            DECnet Phase IV
0029            Appletalk
002b            Novell IPX
002d            Van Jacobson Compressed TCP/IP
002f            Van Jacobson Uncompressed TCP/IP
0031            Bridging PDU
0033            Stream Protocol (ST-II)
0035            Banyan Vines
0037            reserved (until 1993)           [Typo in RFC1172]
0039            AppleTalk EDDP
003b            AppleTalk SmartBuffered
003d            Multi-Link                              [RFC1717]
003f            NETBIOS Framing
0041            Cisco Systems
0043            Ascom Timeplex
0045            Fujitsu Link Backup and Load Balancing (LBLB)
0047            DCA Remote Lan
0049            Serial Data Transport Protocol (PPP-SDTP)
004b            SNA over 802.2
004d            SNA
004f            IPv6 Header Compression
0051            KNX Bridging Data                          [ianp]
0053            Encryption                                [Meyer]
0055            Individual Link Encryption                [Meyer]
0057            Internet Protocol version 6              [Hinden]
0059            PPP Muxing                              [RFC3153]
0061            RTP IPHC Full Header                    [RFC2509]
0063            RTP IPHC Compressed TCP                 [RFC2509]
0065            RTP IPHC Compressed Non TCP             [RFC2509]
0067            RTP IPHC Compressed UDP 8               [RFC2509]
0069            RTP IPHC Compressed RTP 8               [RFC2509]
006f            Stampede Bridging
0071            Reserved                                    [Fox]
0073            MP+ Protocol                              [Smith]
007d            reserved (Control Escape)               [RFC1661]
007f            reserved (compression inefficient)      [RFC1662]
0081            Reserved Until 20-Oct-2000                 [IANA]
0083            Reserved Until 20-Oct-2000                 [IANA]
00c1            NTCITS IPI                                [Ungar]
00cf            reserved (PPP NLPID)
00fb            single link compression in multilink    [RFC1962]
00fd            compressed datagram                     [RFC1962]
00ff            reserved (compression inefficient)

02xx-1exx       (compression inefficient)

0201            802.1d Hello Packets
0203            IBM Source Routing BPDU
0205            DEC LANBridge100 Spanning Tree
0207            Cisco Discovery Protocol                   [Sastry]
0209            Netcs Twin Routing                     [Korfmacher]
020b            STP - Scheduled Transfer Protocol           [Segal]    
020d            EDP - Extreme Discovery Protocol          [Grosser] 
0211            Optical Supervisory Channel Protocol (OSCP)[Prasad]
0213            Optical Supervisory Channel Protocol (OSCP)[Prasad]
0231            Luxcom
0233            Sigma Network Systems
0235            Apple Client Server Protocol             [Ridenour]
0281            MPLS Unicast                              [RFC3032] 
0283            MPLS Multicast                            [RFC3032]
0285            IEEE p1284.4 standard - data packets   [Batchelder]
0287            ETSI TETRA Network Protocol Type 1       [Nieminen]
0289            Multichannel Flow Treatment Protocol       [McCann]

2063            RTP IPHC Compressed TCP No Delta          [RFC2509]
2065            RTP IPHC Context State                    [RFC2509]
2067            RTP IPHC Compressed UDP 16                [RFC2509]
2069            RTP IPHC Compressed RTP 16                [RFC2509]

4001            Cray Communications Control Protocol        [Stage]
4003            CDPD Mobile Network Registration Protocol   [Quick]
4005            Expand accelerator protocol              [Rachmani]
4007            ODSICP NCP                                 [Arvind]      
4009            DOCSIS DLL                                [Gaedtke]
4021            Stacker LZS                               [Simpson]
4023            RefTek Protocol                           [Banfill]
4025            Fibre Channel                           [Rajagopal]
4027            EMIT Protocols                            [Eastham]


8001-801f       Not Used - reserved                       [RFC1661]
8021            Internet Protocol Control Protocol
8023            OSI Network Layer Control Protocol
8025            Xerox NS IDP Control Protocol
8027            DECnet Phase IV Control Protocol
8029            Appletalk Control Protocol
802b            Novell IPX Control Protocol
802d            reserved
802f            reserved
8031            Bridging NCP
8033            Stream Protocol Control Protocol
8035            Banyan Vines Control Protocol
8037            reserved (until 1993)               [See note for 0037]
8039            reserved
803b            reserved
803d            Multi-Link Control Protocol
803f            NETBIOS Framing Control Protocol
8041            Cisco Systems Control Protocol
8043            Ascom Timeplex
8045            Fujitsu LBLB Control Protocol
8047            DCA Remote Lan Network Control Protocol (RLNCP)
8049            Serial Data Control Protocol (PPP-SDCP)
804b            SNA over 802.2 Control Protocol
804d            SNA Control Protocol
804f            IP6 Header Compression Control Protocol
8051            KNX Bridging Control Protocol                    [ianp]
8053            Encryption Control Protocol                     [Meyer]
8055            Individual Link Encryption Control Protocol     [Meyer]
8057            IPv6 Control Protovol                          [Hinden]
8059            PPP Muxing Control Protocol                   [RFC3153]
806f            Stampede Bridging Control Protocol
8073            MP+ Control Protocol                            [Smith]
8071            Reserved                                          [Fox]
807d            Not Used - reserved                           [RFC1661]
8081            Reserved Until 20-Oct-2000                       [IANA]
8083            Reserved Until 20-Oct-2000                       [IANA]
80c1            NTCITS IPI Control Protocol                     [Ungar]
80cf            Not Used - reserved                           [RFC1661]
80fb            single link compression in multilink control  [RFC1962]
80fd            Compression Control Protocol                  [RFC1962]
80ff            Not Used - reserved                           [RFC1661]

8207            Cisco Discovery Protocol Control               [Sastry]
8209            Netcs Twin Routing                         [Korfmacher]
820b            STP - Control Protocol                          [Segal]
820d            EDPCP - Extreme Discovery Protocol Ctrl Prtcl [Grosser]
8235            Apple Client Server Protocol Control         [Ridenour]
8281            MPLSCP                                        [RFC3032]
8285            IEEE p1284.4 standard - Protocol Control   [Batchelder]
8287            ETSI TETRA TNP1 Control Protocol             [Nieminen] 
8289            Multichannel Flow Treatment Protocol           [McCann]

c021            Link Control Protocol
c023            Password Authentication Protocol
c025            Link Quality Report
c027            Shiva Password Authentication Protocol
c029            CallBack Control Protocol (CBCP)
c02b            BACP Bandwidth Allocation Control Protocol     [RFC2125]
c02d            BAP                                            [RFC2125]

c081            Container Control Protocol                         [KEN]
c223            Challenge Handshake Authentication Protocol
c225            RSA Authentication Protocol                   [Narayana]
c227            Extensible Authentication Protocol             [RFC2284]
c229            Mitsubishi Security Info Exch Ptcl (SIEP)         [Seno]
c26f            Stampede Bridging Authorization Protocol
c281            Proprietary Authentication Protocol                [KEN]
c283            Proprietary Authentication Protocol          [Tackabury]
c481            Proprietary Node ID Authentication Protocol        [KEN]



_______________________________________________
L2tpext mailing list
L2tpext <at> ietf.org
https://www1.ietf.org/mailman/listinfo/l2tpext

Permalink | Reply | 0 comments |
headers
HOULLIER Francis FTRD/DMI/CAE | 16 May 2002 17:04

IP Header Compression over PPP and QoS.

Hi all,

I want to use a stack of protocol of this kind :
data / IP in / PPP mux / L2TP / UDP / IP out.

And I've got a question about ToS field :
If IP header compression is negociated over PPP mux, how can the ToS field of IP in be copied in the ToS field of IP out ?

Perhaps the ToS field of IP in is lost, or perhaps IP header compression is not compatible with L2TP tunneling ?
So, if somebody has already met this issue or has got an answer, feel free to tell it to me.

Thank you
Francis

Permalink | Reply | 0 comments |

Gmane