Rede Grupo de Trabalho W.

Simpson, Editor Request for Comments: 1661 Daydreamer DST: 51 jul 1994 Obsoletes: 1548 Categoria: Standards Track O protocolo ponto-a-Ponto (PPP)

Status do presente Memo Este documento especifica um protocolo Internet normas para a pista Comunidade da Internet, e solicita discusso e sugestes para melhorias. Por favor, consulte a edio atual da Internet " Oficiais Protocolo Standards "(1 DST) para o estado de normalizao e do estatuto do presente protocolo. A distribuio deste memorando ilimitado. Abstrato O protocolo ponto-a-Ponto (PPP) fornece um mtodo padro para transporte de datagramas multi-protocolo ponto-a-ponto ligaes. PPP constitudo por trs componentes principais: 1. Um mtodo para encapsular datagramas multi-protocolo. 2. A Link Control Protocol (LCP) para estabelecer, configurar, e testar a conexo de link de dados. 3. Uma famlia de Network Control Protocols (PCN) para o estabelecimento de e configurar diferentes protocolos da camada de rede. Este documento define a organizao e metodologia PPP, ea Encapsulamento PPP, juntamente com uma opo negociao extensvel mecanismo que capaz de negociar uma rica variedade de parmetros de configurao e fornece gerenciamento adicional funes. A ligao PPP Protocolo de Controle de (LCP) descrito em termos deste mecanismo. ndice analtico 1. Introduo .......................................... 1 1,1 Especificao de Requisitos ................... 2 1,2 Terminologia ..................................... 3 2. Encapsulamento PPP ..................................... 4

Simpson [Pgina i]

RFC 1661 Point-to-Point Protocol julho 1994 3. PPP 3.1 3,2 3,3 3,4 3,5 3,6 3,7 Link operao .................................... 6 Viso geral ........................................ 6 Diagrama de Fases ................................... 6 Link Morto (camada fsica-no est pronto) ............ 7 Link Estabelecimento Fase ........................ 7 Autenticao Fase ............................ 8 Fase Network-Layer Protocolo .................... 8 Link Resciso Fase .......................... 9

4. A opo negociao autmato ...................... 11 4,1 Transio Estado Tabela .......................... 12 4.2 Os Estados .......................................... 14 4.3 Eventos .......................................... 16 4.4 Aes ......................................... 21 4,5 Preveno de Loop .................................. 23 4.6 Contadores e temporizadores ............................. 24 5. Formatos de pacotes LCP .................................... 26 5,1 5,2 5,3 5,4 5,5 5,6 5,7 5,8 5,9 Configure-Pedido ............................... 28 Configurar ACK-................................... 29 Configure-Nak ................................... 30 Configure-Rejeitar ................................ 31 Finaliza-Pedidos e encerr-ACK ............. 33 Cdigo-Rejeitar ..................................... 34 Protocolo-Rejeitar ................................. 35 Echo Request e Echo Reply-..................... 36 Discard-Request ................................. 37

6. Opes de configurao LCP ............................. 39 6,1-Maximum Receive Unit (MRU) ...................... 41 6,2 Authentication Protocol-......................... 42 6,3 Qualidade-Protocolo ................................ 43 6,4 nmero mgico-.................................... 45 6,5 Protocolo-Campo-Compresso (PFC) ................ 48 6,6 Endereo de e-Control-Campo-Compresso (ACFC) CONSIDERAES DE SEGURANA ...................................... 51 Referncias ................................................. .. 51 AGRADECIMENTOS ............................................. 51 Endereo do presidente .............................................. 52 ENDEREO DO EDITOR ............................................. 52

Simpson [Pgina ii]

RFC 1661 Point-to-Point Protocol julho 1994 1. Introduo O protocolo ponto-a-Ponto projetado para os links que simples transporte de pacotes entre dois pares. Estas ligaes fornecem full-duplex simultnea bi-direccional, operao e so assumidos para entregar pacotes em ordem. Pretende-se que PPP fornecer uma soluo comum para uma fcil ligao de uma ampla variedade de hospedeiros, pontes e encaminhadores [1]. Encapsulamento O encapsulamento PPP prev a multiplexao de diferentes camada de rede protocolos simultaneamente sobre o mesmo link. O Encapsulamento PPP foi cuidadosamente projetado para manter compatibilidade com mais comumente utilizado hardware de suporte. Somente 8 octetos adicionais so necessrias para formar o encapsulamento quando usados dentro do padro de enquadramento HDLC-like. Em ambientes onde a banda est em um prmio, o encapsulamento e enquadramento pode ser reduzido para 2 ou 4 octetos. Para suportar implementaes de alta velocidade, o encapsulamento padro usa somente campos simples, das quais apenas uma deve ser analisada para demultiplexao. O cabealho padro e campos de informao queda de 32 bits limites, eo trailer pode ser preenchido com um limite arbitrrio. Link Control Protocol A fim de ser suficientemente verstil para ser porttil para uma gama variedade de ambientes, proporciona uma PPP Link Control Protocol (LCP). A LCP usado automaticamente para acordar o opes de formato de encapsulamento, lidar com diferentes limites de tamanhos de pacotes, detectar uma ligao loop-back e outro comum errada erros, e encerrar a ligao. Outro opcional facilidades oferecidas so a autenticao da identidade dos seus pares sobre o link, e determinao quando um link est funcionando corretamente e quando ele est falhando. Controle de protocolos de rede Point-to-Point relaes tendem a agravar muitos problemas com a atual famlia de protocolos de rede. Por exemplo, a cesso e gesto de endereos IP, que um problema, mesmo em LAN

ambientes, especialmente difcil ao longo de comutao de circuitos ponto-a-ponto links (tais como servidores de modem dial-up). Estes problemas so tratados por uma famlia de protocolos de rede Controle (PCN), que cada gerir as necessidades especficas exigidas pela sua

Simpson [Pgina 1]

RFC 1661 Point-to-Point Protocol julho 1994 respectivos protocolos de camada de rede. Estas so definidas nos PCN companheiro documentos. Configurao Pretende-se que ligaes PPP ser fcil de configurar. Pelo projeto, os padres normais lidar com todas as configuraes comuns. O implementor pode especificar melhorias para a configurao padro, que so automaticamente comunicados ao ponto, sem operador interveno. Finalmente, o operador pode configurar explicitamente opes para o link que permitem a ligao a funcionar em ambientes onde de outra forma seriam impossveis. Esta auto-configurao implementado atravs de uma extensvel mecanismo de opo negociao, onde cada extremidade da ligao descreve para os outros as suas capacidades e necessidades. Embora o mecanismo de negociao opo descrito neste documento especificada em termos do Link Control Protocol (LCP), as mesmas instalaes so concebidos para ser utilizados por outro controle protocolos, principalmente a famlia dos PCN.

1,1. Especificao de Requisitos Neste documento, vrias palavras so usadas para indicar os requisitos da especificao. Estas palavras so frequentemente capitalizados. DEVE Esta palavra, ou o adjectivo "necessrias", significa que o definio um requisito absoluto da especificao. NO DEVE Essa frase significa que a definio uma necessidade absoluta proibio da especificao. DEVE Esta palavra, ou o adjectivo "recomendados", significa que h Podem existir razes vlidas em circunstncias particulares para ignorar esse item, mas as suas implicaes devem ser compreendida e ponderou cuidadosamente antes de escolher um curso diferente. Que esta palavra, ou o adjectivo "opcional", significa que este um item de um conjunto de alternativas permitidas. Um implementao que no inclua esta opo deve ser preparada para interoperar com outra aplicao que no inclui a opo.

Simpson [Pgina 2]

RFC 1661 Point-to-Point Protocol julho 1994 1,2. Terminologia Este documento utiliza frequentemente os seguintes termos: datagrama A unidade de transmisso na camada de rede (como IP). Um datagrama podem ser encapsulados em um ou mais pacotes passado para a camada de enlace de dados. frame A unidade de transmisso na camada de enlace de dados. Um quadro pode incluir um cabealho e / ou de um reboque, juntamente com alguns nmero de unidades de dados. pacote A unidade bsica de encapsulamento, que passado atravs da interface entre a camada de rede e da ligao de dados camada. Um pacote geralmente mapeado para um quadro, o excees so quando os dados fragmentao da camada de enlace est sendo executado, ou quando vrios pacotes so incorporadas num nico frame. Os outros pares final da ligao de ponto-a-ponto. silenciosamente descartar A implementao descarta o pacote, sem mais processamento. A aplicao deve proporcionar a capacidade de log de erro, incluindo o contedo de o pacote descartado silenciosamente, e deve registrar o evento num contador de estatsticas.

Simpson [Pgina 3]

RFC 1661 Point-to-Point Protocol julho 1994 2. Encapsulamento PPP O encapsulamento PPP usado para desambiguar multiprotocolo datagramas. Isso requer um enquadramento encapsulamento para indicar a incio e no fim do encapsulamento. Mtodos de fornecer enquadramento so especificados nos documentos do companheiro. Um resumo do encapsulamento PPP mostrado abaixo. Os campos so transmitidos da esquerda para a direita. + | | + ---------- + ------------- + --------- + Protocolo | Informaes | Preenchimento | 8/16 bits | * | * | ---------- + ------------- + --------- +

Campo Protocolo O campo protocolo um ou dois octetos, e seu valor identifica o datagrama encapsulado no campo de informao do pacote. O campo transmitida e recebida octeto mais significativo em primeiro lugar. A estrutura deste campo consistente com a norma ISO 3309 mecanismo de extenso para os campos de endereo. Todos os protocolos devem ser impar, o bit menos significativo do octeto menos significativo deve igual "1". Alm disso, todos os protocolos devem ser atribudos de modo que o bit menos significativo do octeto mais significativo igual a "0". Quadros recebidos que no cumpram estas regras devem ser tratados como tendo um protocolo despercebidas. Protocolo valores no campo "0 ***" para "3 ***" faixa de identificar o camada de rede protocolo de pacotes especficos, e os valores em "*** 8" para "b ***" faixa de identificar os pacotes que pertencem associado Network Control Protocols (PCN), se houver. Protocolo valores no campo "4 ***" para "7 ***" gama so utilizados para protocolos com baixo volume de trfego que no tm associado PCN. Protocolo valores no campo do "c ***" a "f ***" gama identificar pacotes como protocolos de camada de enlace de controle (como LCP).

Simpson [Pgina 4]

RFC 1661 Point-to-Point Protocol julho 1994 Up-to-date valores do protocolo domnio so especificados na maioria recentes "Assigned Numbers" RFC [2]. As reservas deste especificaes os seguintes valores: Valor Nome Protocol (em hexadecimal) 0001 001f 007d 00cf 00ff 8001 807d 80cf 80ff C021 c023 C025 C223 Padding Protocolo reservados para 0003 (transparncia ineficiente) reservados (Controle Escape) reservados (PPP NLPID) reservados (compresso ineficiente) a 801f no utilizado no utilizado no utilizado no utilizado Link Control Protocol Password Authentication Protocol Relatrio Link Quality Challenge Handshake Authentication Protocol

Os desenvolvedores de novos protocolos deve obter um nmero a partir da Internet Assigned Numbers Authority (IANA), no IANA@isi.edu. Campo de Informao O campo de informao zero ou mais octetos. A Informao campo contm o datagrama para o protocolo especificado no Protocolo campo. O comprimento mximo para o campo da informao, incluindo estofamento, mas no incluindo o campo de protocolo, denominado o mximo Receber Unit (MRU), cujo padro 1500 octetos. Por negociao, consentindo PPP implementaes podem usar outros valores para o MRU. Acolchoamento A transmisso, ao domnio da informao podem ser preenchidos com um nmero arbitrrio de octetos at o MRU. o responsabilidade de cada protocolo para distinguir octetos do estofo informao real.

Simpson [Pgina 5]

RFC 1661 Point-to-Point Protocol julho 1994 3. PPP Link operao 3,1. Viso global A fim de estabelecer as comunicaes atravs de um link ponto-aponto, cada fim da ligao PPP primeiro deve enviar pacotes LCP para configurar e testar a ligao de dados. Aps a ligao tiver sido estabelecida, os pares podem ser autenticado. Em seguida, as PPP devem enviar pacotes NCP para escolher e configurar um ou mais rede camada protocolos. Uma vez que cada um dos escolhidos de camada de rede protocolos foi configurado, datagramas de cada camada de rede protocolo pode ser enviado atravs do link. O link permanecer configurado para comunicaes at explcito LCP PCN pacotes ou fechar a ligao para baixo, ou at que algum evento externo ocorre (um temporizador expira inatividade ou administrador de rede interveno).

3,2. Diagrama de Fases No processo de configurao, manuteno e encerra o ponto-a-ponto link, o link PPP passa por vrios distinta fases que so especificados no diagrama de estados simplificado a seguir: + | | | + ------ + + ----------- + + -------------- + | UP | | ABERTO | SUCESSO / NONE | Dead | -------> | Estabelecer | ----------> | Autenticar | - + | | | | | | ------ + + ----------- + + -------------- + | ^ | | | | FAIL | FAIL | | + <-------------- + + ---------- + | | | | | + ----------- + | + --------- + | | BAIXO | | Encerramento | | | | + ------------ | Termina | <--- + <---------- | Rede | <- + | | | | + ----------- + + --------- +

Nem todas as transies so especificadas neste diagrama. A seguir semntica deve ser seguido.

Simpson [Pgina 6]

RFC 1661 Point-to-Point Protocol julho 1994 3,3. Link Dead (no de camada fsica pronta) A ligao necessariamente comea e termina com esta fase. Quando um evento externo (como a deteco de transportadora ou administrador de rede configurao) indica que a camada fsico-est pronto para ser usado, PPP vai avanar para a fase de estabelecimento da ligao. Durante esta fase, o autmato LCP (descrito mais tarde) estar na Estados iniciais ou de partida. A transio para o Estabelecimento Link fase ir sinalizar um evento at o autmato LCP. Nota de Implementao: Tipicamente, um link vai voltar a esta fase automaticamente aps a desconexo de um modem. No caso de uma ligao hard-wired, esta fase pode ser extremamente curto - apenas o tempo suficiente para detectar a presena do dispositivo.

3,4. Link Estabelecimento Fase O Protocolo de ligao atravs de uma Inaugurado LCP Configure-Ack (Descrito mais Controle de ligao (LCP) usado para estabelecer a troca de pacotes Configurar. Esta troca completa, e do estado inscrito, uma vez que um pacote adiante) foi enviadas e recebidas.

Todas as opes de configurao esto a ser assumida em valores padro, a menos alterada pela troca de configurao. Veja o captulo sobre LCP Opes de configurao para uma discusso mais aprofundada. importante notar que apenas de Configurao que so independente da rede particular de camada protocolos so configurados pelo LCP. Configurao de rede individuais camada protocolos tratado por protocolos de rede distintos de Controle (PCN) durante o Network-Layer Protocolo de fase. Qualquer no-LCP pacotes recebidos durante esta fase deve ser silenciosamente descartado. A recepo do LCP Configure-Pedido provoca um retorno ao link Fase de estabelecimento da fase de protocolo de camada de rede ou Fase de autenticao.

Simpson [Pgina 7]

RFC 1661 Point-to-Point Protocol julho 1994 3,5. Fase de Autenticao Em algumas ligaes, pode ser desejvel para exigir um peer para autenticar se antes de permitir que os pacotes de camada de rede de protocolo para ser trocados. Por padro, a autenticao no obrigatria. Se uma implementao desejos que os pares autenticar com alguma autenticao especfico protocolo, em seguida, ele deve solicitar o uso de autenticao que protocolo durante a fase de estabelecimento da ligao. A autenticao dever ter lugar logo que possvel aps ligao estabelecimento. No entanto, link qualidade determinao pode ocorrer simultaneamente. Uma implementao no devem permitir a troca de link pacotes de determinao de qualidade autenticao para atrasar indefinidamente. Avano da fase de autenticao da Camada de RedeProtocolo fase no deve ocorrer at que a autenticao foi concluda. Se autenticao falhar, o autenticador dever proceder ao invs Link Resciso fase. Apenas Link Control Protocol, protocolo de autenticao, e qualidade da ligao pacotes de monitoramento so permitidos durante esta fase. Todos os outros pacotes recebeu durante esta fase deve ser descartado silenciosamente. Notas de Implementao: Uma implementao no deve falhar simplesmente devido a autenticao timeout ou falta de resposta. A autenticao deve permitir que alguns mtodo de retransmisso, e siga para o Link Resciso fase apenas aps uma srie de tentativas de autenticao tem sido excedido. O responsvel pela execuo inicia Link Resciso fase a implementao que se recusou a autenticao seus pares.

3,6. Camada de Rede-Fase Protocolo Uma vez terminado o PPP tem fases anteriores, cada camada de rede protocolo (como IP, IPX ou AppleTalk) deve ser separado configurado pelo adequado Network Control Protocol (NCP). Cada PCN podem ser abertas e fechadas a qualquer momento.

Simpson [Pgina 8]

RFC 1661 Point-to-Point Protocol julho 1994 Nota de Implementao: Porque uma aplicao pode inicialmente utilizar uma quantidade significativa de tempo para determinao da qualidade da ligao, implementaes devem evitar timeouts fixos quando esperam por seus pares para configurar um NCP. Depois de um PCN atingiu o Aberto estado, vai levar o PPP correspondentes pacotes de camada de rede de protocolo. Qualquer suportado pacotes de camada de rede do protocolo recebido quando o PCN correspondente no inaugurado no Estado deve ser descartado silenciosamente. Nota de Implementao: Enquanto LCP inaugurado no Estado, qualquer que seja protocolo packet incompatvel com a implementao deve ser devolvido em um protocoloRejeitar (descrito mais tarde). S protocolos que so suportados so silenciosamente descartado. Durante esta fase, o trfego de ligao consiste em qualquer combinao possvel da LCP, NCP, e pacotes de camada de rede de protocolo.

3,7. Link Resciso Fase PPP pode encerrar a ligao a qualquer momento. Isso pode acontecer por causa da a perda da transportadora, a autenticao falha, falha a qualidade do link, expirao de um temporizador do perodo ocioso, ou o encerramento administrativo do link. LCP utilizado para fechar a ligao atravs de uma troca de Terminar pacotes. Quando a ligao fechar, PPP informa a camada de rede protocolos para que possam tomar medidas adequadas. Aps a troca de pacotes Finaliza, a implementao deve sinalizar a camada fsica para desconectar, a fim de cumprir a cessao da ligao, particularmente no caso de um falha de autenticao. O remetente da solicitao deve-Encerrar desconectar aps receber um Finaliza-ACK, ou aps a reinicializao contador expirar. O receptor de um Terminate-Request deve esperar pares para o desligar, e no deve desligar at que pelo menos um Reinicie o tempo passou depois de enviar um Finaliza-ACK. PPP DEVE avanar para a fase de ligao inoperante.

Qualquer no-LCP pacotes recebidos durante esta fase deve ser silenciosamente descartado.

Simpson [Pgina 9]

RFC 1661 Point-to-Point Protocol julho 1994 Nota de Implementao: O encerramento da ligao por LCP suficiente. No h necessidade para cada PCN para enviar uma enxurrada de pacotes Finaliza. Inversamente, o fato de que tenha fechado um PCN no razo suficiente para causar a cessao da ligao PPP, mesmo que NCP foi o PCN apenas atualmente no estado Aberto.

Simpson [Pgina 10]

RFC 1661 Point-to-Point Protocol julho 1994 4. A opo negociao autmato O autmato finito de estado definido pelos acontecimentos, aes e estaduais transies. Os eventos incluem a recepo de comandos externos, tais como Abertura e Fechamento de validade, de Reinicie o temporizador, e recepo de pacotes a partir de um ponto. As aes incluem o incio das Restart temporizador e transmisso de pacotes para os pares. Alguns tipos de pacotes - configure-Naks e Configure-Rejeita, ou Cdigo-Rejeita e Protocolo Rejects, ou Echo-Pedidos, Echo-Respostas e Descarte de pedidos - no so diferenciados no autmato descries. Como ser descrito mais tarde, estes pacotes realmente tm funes diferentes. No entanto, eles provocam sempre o mesmo transies. Aes Eventos Up = camada inferior Up tlu = Este Layer--Up Down = camada inferior baixo tld = Este Layer--Down Open = Abrir administrativa tls = Este Layer-IniciadoClose = Fechar administrativa tlf = Este Layer-acabados A + = Timeout com contador> 0 irc = Inicializar-Restart-Count TO-Timeout = terminou com a contra ZrC = Zero-Restart-Count RCR + Request RCR-= RCA = RCN = = Recebe-Configure-Request (Bom) = scr Envie-ConfigureRecebe-Configure-Request (Ruim) Recebe-Configure-Ack sca = Enviar-Configure-Ack scn Receive-Configure-Nak/Rej = Send-Configure-Nak/Rej

RTR = str Recebe-Finaliza-Pedidos = Envia-Terminate-Request RTA = Recebe-Finaliza-ACK = sta Envie-Finaliza-ACK RUC = Recebe-Desconhecido-Cdigo scj = Enviar Cdigo-Rejeitar RXJ + = Recebe-Cdigo-Rejeitar (permitido) ou receber-Protocolo-Rejeitar RXJ-= Recebe-Cdigo-Rejeitar (catastrfico) ou receber-Protocolo-Rejeitar RXR = Recebe-echo-request sr = Envia-Echo ReplyReceber ou-Echo Replyou receber-Discard-Request

Simpson [Pgina 11]

RFC 1661 Point-to-Point Protocol julho 1994 4,1. Tabela de Transio de Estados A tabela completa transio estado segue. Estados so indicados horizontalmente, e os eventos so lidos verticalmente. Estado e transies aes so representadas na forma aco / estado-novo. Mltiplo aes so separados por vrgulas, e pode continuar a ter sucesso linhas como espao requer; aces mltiplas pode ser implementada em qualquer ordem conveniente. O estado pode ser seguido por uma letra, o qual indica uma nota explicativa. O hfen ("-") indica uma transio ilegal. | Estado | 0 1 2 3 4 5 Eventos | Encerramento de partida inicial fechado Parado Parar ------ + ------------------------------------------- ---------------Up | 2 irc, scr / ---- 6 Para baixo | - 0 tls / 1 0 1 Aberto | tls / 1 1 irc, scr / 6 3r 5r 5r Feche | 0 tlf / 0 2 2 4 4 | A + | ---- str / 4 str / 5 TO-| ---- tlf / 2 tlf / 3 | RCR + | - sta / 2 irc, scr, SCA / 8 4 5 RCR-| - sta / 2 irc, scr, SCN / 6 4 5 RCA | - sta / 2 sta / 3 4 5 RCN | - sta / 2 sta / 3 4 5 | RTR | - sta / 2 sta / 3 sta / 4 sta / 5 RTA | - tlf 2 3/2 tlf / 3 | RUC | - scj / 2 scj / 3 scj / 4 scj / 5 RXJ + | - 2 3 4 5 RXJ-| - tlf / 2 tlf / 3 tlf / 2 tlf / 3 | RXR | - 2 3 4 5

Simpson [Pgina 12]

RFC 1661 Point-to-Point Protocol julho 1994

| Estado | 6 7 8 9 Eventos | Req-Sent-Ack Ack-Sent Rcvd Aberto ------ + ----------------------------------------Up | ---Down | 1 1 1 tld / 1 Abra | 6 7 8 9r Fechar | irc, str / 4 IRC, str / 4 IRC, str / 4 TLD, IRC, str / 4 | A + | scr / 6 scr / 6 scr / 8 TO-| tlf/3p tlf/3p tlf/3p | RCR + | sca / 8 sca, tlu / 9 sca / 8 TLD, scr, SCA / 8 RCR-| scn / scn 6 / scn 7/6 TLD, scr, SCN / 6 RCA | irc / 7 scr/6x irc, tlu / 9 tld, scr/6x RCN | irc, scr / 6 scr/6x irc, scr / 8 tld, scr/6x | RTR | sta / 6 sta / 6 sta / 6 tld, ZrC, sta / 5 RTA | 6 6 8 TLD, scr / 6 | RUC | scj / 6 scj / 7 scj / 8 scj / 9 RXJ + | 6 6 8 9 RXJ-| tlf / 3 tlf / 3 tlf / 3 TLD, IRC, str / 5 | RXR | 6 7 8 Ser / 9 Os estados em que a Restart temporizador estiver executando so identificveis por a presena de a eventos. Somente o Send-Configure-Request, EnviarAes rescindir solicitao e Zero-Restart-Count iniciar ou reiniciar Reinicie o temporizador. Reinicie o timer parado quando a transio a partir de qualquer estado onde o cronmetro est correndo para um estado onde o temporizador no est funcionando. Os eventos e aes so definidas de acordo com uma passagem de mensagens arquitetura, ao invs de uma arquitetura de sinalizao. Se uma ao desejado para controlar sinais especficos (como DTR), aes adicionais so susceptveis de ser necessria. [P] opo passiva; ver Parado estado discusso. [R] opo Reiniciar; ver discusso evento Open. [X] Crossed conexo; ver RCA evento discusso.

Simpson [Pgina 13]

RFC 1661 Point-to-Point Protocol julho 1994 4,2. Estados Segue uma descrio mais detalhada de cada estado autmato. Inicial No estado inicial, a camada inferior indisponvel (baixo), e Abra no tenha ocorrido. Reinicie o timer no est funcionando na Estado inicial. Iniciando O estado inicial o Open contrapartida para o estado inicial. An Open administrativa foi iniciada, mas a camada inferior ainda indisponvel (baixo). Reinicie o timer no est funcionando na A partir do estado. Quando a camada inferior torna-se disponvel (para cima), um Configure-Request enviado. Fechado No estado fechado, o link est disponvel (para cima), mas no tem Open ocorreu. Reinicie o timer no est sendo executado no estado fechado. Aquando da recepo de Configurar Pedido de pacotes, um Finaliza-ACK enviada. Acks encerrar-se silenciosamente eliminados para evitar a criao de um loop. Parado A Parada o Open contrapartida para o estado fechado. Ele inscrita quando o autmato est esperando por um evento de Down aps Esta aco-Layer acabados, ou depois de enviar um Finaliza-ACK. Reinicie o timer no est funcionando no estado Parado. Aquando da recepo de Configurar Pedido de pacotes, um adequado resposta enviada. Aps a recepo de outros pacotes, um FinalizaACK enviado. Acks encerrar-se silenciosamente descartado para evitar criando um lao. Justificativa: A Parada um estado de juno para a terminao da ligao, falha no link de configurao, e outros modos de falha do autmato. Esses estados potencialmente distintos foram combinados.

Existe uma condio de corrida entre a resposta do evento de Down (partir

Simpson [Pgina 14]

RFC 1661 Point-to-Point Protocol julho 1994 o Esta-Layer-Concludo ao) eo Recebe-ConfigureSolicite evento. Quando um Configure-Request chega antes do Abaixo evento, o evento de Down vai substituir a devoluo do autmato ao estado inicial. Isto evita o ataque por repetio. Execuo Opo: Aps o peer no para responder a Configure-Os pedidos, um implementao pode esperar passivamente pelos pares para enviar Configurar-Pedidos. Neste caso, o presente Camada-acabamento ao no usado para o evento-TO nos estados Req-Sent, ACKRcvd e Ack-Sent. Esta opo til para circuitos dedicados, ou circuitos que no tm estatuto sinais disponveis, mas no deve ser utilizado para comutada circuitos. Encerramento No estado de Encerramento, feita uma tentativa de rescindir o conexo. Finaliza-Um pedido foi enviado eo Restart temporizador est funcionando, mas um Finaliza-ACK ainda no foi recebido. Aps a recepo de uma Finaliza-ACK, o Estado fechado inscritas. Aps a expirao do temporizador Restart, um novo FinalizaPedidos transmitida, e Reinicie o timer reiniciado. Aps o Reinicie o temporizador expirou Max-Finaliza vezes, o Estado fechado entrou. Paragem Parando o Estado o Open contrapartida para o estado de Encerramento. Finaliza-Um pedido foi enviado e da Restart temporizador em execuo, mas uma Finaliza-ACK ainda no tenha sido recebido. Justificativa: O estado de paragem fornece uma oportunidade para bem definidos encerrar uma ligao antes de permitir o trfego de novo. Aps a ligao tenha terminado, uma nova configurao pode ocorrer atravs da Parado Iniciando ou estados. Pedido enviado de No estado-Request Sent feita uma tentativa para configurar o conexo. A Configure-Pedido foi enviado eo Restart

temporizador est funcionando, mas uma Configurar ACK-ainda no foi recebida

Simpson [Pgina 15]

RFC 1661 Point-to-Point Protocol julho 1994 nem tem sido um enviado. ACK-Recebido No estado ACK-recebidas, uma Configure-Pedido foi enviado um e Configure-ACK foi recebido. Reinicie o timer ainda executando, desde uma Configurar ACK ainda no foi enviado. ACK-SENT No estado ACK-SENT, uma Configure-Request e um Configure-Ack ambos tm sido enviada, mas uma Configurar ACK-ainda no foi recebido. Reinicie o timer estiver em execuo, uma vez que uma Configure-Ack tem ainda no foi recebido. Aberto Inaugurado no Estado, uma Configure-ACK tenha sido enviadas e recebido. Reinicie o timer no est funcionando. Ao entrar no Aberto estado, a execuo dever sinalizar as camadas superiores que cabe agora. Inversamente, quando o deixando Inaugurado estado, a execuo dever assinalar as camadas superiores que agora Down.

4,3. Eventos Transies e aes do autmato so causados por eventos. Para cima Este evento ocorre quando uma camada inferior indica que ele est pronto para transportar pacotes. Normalmente, este evento usado por um modem manipulao ou apelando processo, ou por algum outro engate da ligao PPP para o fsico mdia, para sinalizar LCP que o link est entrando Link Estabelecimento fase. Tambm pode ser usado por LCP para sinalizar cada NCP que a ligao entrar Network-Layer Protocolo fase. Isto , o presente-Layer-Up ao da LCP aciona o evento Up no NCP. Para baixo Este evento ocorre quando uma camada inferior indica que no

Simpson [Pgina 16]

RFC 1661 Point-to-Point Protocol julho 1994 mais pronto para transportar pacotes. Normalmente, este evento usado por um modem manipulao ou apelando processo, ou por algum outro engate da ligao PPP para o fsico mdia, para sinalizar LCP que o link est entrando em fase de ligao inoperante. Tambm pode ser usado por LCP para sinalizar cada NCP que a ligao deixando Network-Layer Protocolo fase. Isto , o-Este LayerAbaixo ao de LCP aciona o evento de Down no NCP. Aberto Este evento indica que o link administrativamente disponvel para o trfego, isto , o administrador de rede (humana ou programa) indicou que o link est autorizado a ser aberto. Quando este evento ocorre, ea ligao no inaugurado no Estado, o autmato tentar enviar pacotes de configurao para os pares. Se o autmato no capaz de iniciar a configurao (inferior camada baixo, ou um evento anterior Close no foi concludo), o estabelecimento da ligao automaticamente adiado. Quando um Terminate-Request for recebida, ou outros eventos ocorrem que fazer com que o link para se tornarem indisponveis, o autmato vai avanar para um estado onde o link est pronto para voltar a abrir. Nenhum adicional interveno administrativa necessria. Execuo Opo: A experincia tem mostrado que os usurios iro executar um adicional Aberto comando quando eles querem renegociar o link. Isso poderia indicam que novos valores devem ser negociados. Uma vez que este no o significado do evento aberto, sugeriu que, quando um comando do usurio aberto executado no Inaugurado, Fechar, parando ou parado estados, o problema de implementao de um evento de Down, seguida imediatamente por uma At evento. Cuidados devem ser tomados para que um evento intervir de Down no pode ocorrer de outra fonte. O baixo seguido por um Up ir causar uma renegociao ordenada da ligao, por progredir atravs do Comeando Pedido enviado de Estado. Isso far com que a renegociao da link, sem quaisquer efeitos secundrios nocivos.

Fechar Este evento indica que o link no est disponvel para o trfego;

Simpson [Pgina 17]

RFC 1661 Point-to-Point Protocol julho 1994 isto , o administrador de rede (humana ou de programa) tem indicaram que o link no permitido para ser aberto. Quando este evento ocorre, ea ligao no est no estado de fechado, o autmato tenta finalizar a ligao. Tentativas Futher para re-configurar a ligao negado at que um novo evento aberto ocorre. Nota de Implementao: Quando a autenticao falhar, o link deve ser encerrado, a impedir o ataque por repetio e negao de servio a outro usurios. Uma vez que a ligao administrativamente disponvel (por definio), isto pode ser conseguido por meio da simulao um Fechar evento para o LCP, imediatamente seguido por um evento Open. Cuidados Devem ser tomadas em que um evento de intervir Fechar no pode ocorrer a partir outra fonte. A Fechar seguido por um Open causar o encerramento ordenado do link, por progredir atravs do Final da Parada Estado, ea ao Esta-Layer-Concludo pode desconectar o link. O autmato espera nos estados Parado ou Iniciando para a prxima tentativa de conexo. Timeout (TO +, A-) Este evento indica a expirao do temporizador Restart. O Reinicie o timer usado para respostas em tempo configurarSolicitar e Encerrar Pedido de pacotes. A para evento + indica que o contador de reinicializao continua a ser maior que zero, o que desencadeia a correspondente ConfigureSolicitar ou Finaliza-Pedidos pacote para ser retransmitido. O evento TO-indica que o contador de reinicializao no maior do que zero, e os pacotes no mais precisa ser retransmitido. Recebe-Configure-Request (RCR +, RCR) Este evento ocorre quando um pacote Configure-Request for recebida os pares. O pacote Configure-Pedido indica o desejo de abrir uma conexo e pode especificar opes de configurao. O Configure-Pedido de pacote mais completamente descrita em um posterior seco. O evento RCR + indica que o Configure-Pedido foi aceitvel, e desencadeia a transmisso de um correspondente Configure-ACK. O RCR evento indica que o Configure-Pedido foi

Simpson [Pgina 18]

RFC 1661 Point-to-Point Protocol julho 1994 inaceitvel, e desencadeia a transmisso de um correspondente Configure-Nak ou Configure-Rejeitar. Nota de Implementao: Estes eventos podem ocorrer em uma conexo que j est na Inaugurado estado. A implementao deve estar preparado para imediatamente renegociar as opes de configurao. Recebe-Configure-Ack (RCA) Este evento ocorre quando um pacote Configure-Ack vlida for recebida a partir de pares. O pacote Configure-Ack uma resposta positiva para um pacote Configure-Request. Um fora de seqncia ou de outra forma invlido pacote descartado silenciosamente. Nota de Implementao: Uma vez que o pacote correcta j foi recebido antes atingindo os estados Ack-RCVD ou aberto, extremamente improvvel que outro pacote como vai chegar. Conforme especificado, todos os invlidos ACK / NAK / Rej pacotes so silenciosamente descartados, e fazer no afetar as transies do autmato. No entanto, no corretamente chegar atravs mais provvel implementao. No mnimo, esta impossvel que um pacote formado de uma coincidncia-timed conexo cruzada. que seja o resultado de um erro de ocorrncia deve ser registrada.

Receive-Configure-Nak/Rej (RCN) Este evento ocorre quando um vlido Configure-Nak ou ConfigureReject pacote recebido a partir de pares. A Configure-Nak e Configure-Rejeitar pacotes so respostas negativas a um ConfigureSolicitao de pacote. Um fora de seqncia ou de outra forma de pacote invlido silenciosamente descartado. Nota de Implementao: Embora o Configure-Nak e Configure-Rejeitar causar o mesmo transio de estado no autmato, estes pacotes tm efeitos significativamente diferentes sobre as opes de configurao enviado no pacote resultante Configure-Request. Recebe-Finaliza-Pedido (RTR)

Este evento ocorre quando um pacote Terminate-Request for recebido. O pacote Terminate-Request indica o desejo do peer-to-

Simpson [Pgina 19]

RFC 1661 Point-to-Point Protocol julho 1994 fechar a conexo. Nota de Implementao: Este evento no idntica para o evento de fechar (ver acima), e no substitui os comandos Open da rede local administrador. A implementao deve ser preparado para receber um novo Configure-Pedido sem administrador de rede interveno. Recebe-Finaliza-ACK (RTA) Este evento ocorre quando um pacote encerr-ACK recebido do peer. O pacote de encerr-ACK geralmente uma resposta a um Terminate-Request packet. O pacote Terminate-Ack pode tambm indicam que o ponto em estados de defeso ou parado, e serve para re-sincronizar a configurao link. Recebe-Desconhecido-Code (RUC) Este evento ocorre quando um pacote un-interpretvel recebida a partir os pares. Um pacote de cdigo-Rejeitar enviado em resposta. Receber Cdigo-Rejeitar, Recebe-Protocolo-Rejeitar (RXJ +, RXJ) Este evento ocorre quando um Cdigo-Rejeitar ou um ProtocoloRejeitar pacotes recebida a partir de pares. O evento + RXJ surge quando o valor rejeitado aceitvel, tal como um Cdigo-Rejeitar de um cdigo estendido, ou um ProtocoloRejeitar de um NCP. Estes esto dentro do mbito de funcionamento normal. O implementao deve parar de enviar o tipo de pacote de ofensa. O RXJ evento surge quando o valor rejeitado catastrfica, como um cdigo-Rejeitar do Configure-Request, ou um ProtocoloRejeitar da LCP! Este evento comunica um erro irrecupervel que encerra a conexo. Receber Echo-Request, Recebe-Echo-Responder, Receber-DiscardRequest (RXR) Este evento ocorre quando um echo-request, Echo Reply-ou-Discard Pacote de solicitao recebida a partir de pares. O pacote Echo-Responder uma resposta a um pacote Echo Request. No h resposta a um Echo-Responder ou Discard-Request packet.

Simpson [Pgina 20]

RFC 1661 Point-to-Point Protocol julho 1994 4,4. Aes Aes do autmato so causados por eventos e normalmente indicam a transmisso de pacotes e / ou o ponto de partida ou a paragem do Reinicie o timer. Evento ilegal (-) Isto indica um evento que no pode ocorrer em um adequadamente implementado autmato. A aplicao tem um erro interno, que devem ser notificados e registrados. Nenhuma transio tomada, e a implementao no dever repor ou congelar. Esta-Layer-Up (UAT) Esta ao indica para as camadas superiores que o autmato entrar no estado Aberto. Tipicamente, esta aco usado pelo LCP para sinalizar o evento Up a um protocolo de qualidade NCP, o protocolo de autenticao, ou ligao, ou Pode ser usado por um NCP para indicar que a ligao est disponvel para o seu trfego de camada de rede. Esta camada-Down (TLD) Esta ao indica para as camadas superiores que o autmato deixando o estado Aberto. Tipicamente, esta aco usado pelo LCP para sinalizar o evento de Down a um protocolo de qualidade NCP, o protocolo de autenticao, ou ligao, ou Pode ser usado por um NCP para indicar que a ligao no mais disponvel para o seu trfego de camada de rede. Esta-Layer-Introduo (TLS) Esta aco indica para as camadas inferiores que o autmato entrar no estado inicial, ea camada inferior necessria para a link. A camada inferior deve responder com um evento para cima quando o camada inferior est disponvel. O resultado desta ao so altamente dependente da implementao. Esta-Layer-Concludo (tlf) Esta aco indica para as camadas inferiores que o autmato entrar nas inicial, os Estados de defeso ou parado, e as mais baixas camada no mais necessrio para o link. A camada inferior Deveria

responder com um evento de Down, quando a camada inferior foi encerrado.

Simpson [Pgina 21]

RFC 1661 Point-to-Point Protocol julho 1994 Normalmente, essa ao pode ser utilizado pela LCP para avanar para o Link Morto fase, ou pode ser usado por um NCP para indicar ao LCP que o link pode terminar quando no houver PCN outros abertos. O resultado desta ao so altamente dependente da implementao. Inicializar-Restart-Count (irc) Esta ao define o Restart contador para o valor apropriado (Max-Finaliza-Max ou Configurar). O contador diminudo para cada transmisso, incluindo o primeiro. Nota de Implementao: Alm de definir o contador de reincio, a implementao Deve definir o perodo de tempo limite para o valor inicial quando Reiniciar temporizador backoff usado. Zero-Restart-Count (ZrC) Esta ao define o Restart contador a zero. Nota de Implementao: Esta ao permite que o FSA para fazer uma pausa antes de prosseguir para o desejado estado final, permitindo que o trfego a ser processado pelo peer. Alm truncatura o contador de reinicializao, o implementao deve definir o perodo de tempo limite para uma adequada valor. Envie-Configure-Request (scr) Um pacote Configure-Pedido transmitida. Isto indica que o desejo de abrir uma conexo com um determinado conjunto de configurao Opes. Reinicie o timer iniciado quando o Configure-Request pacote transmitido, para se proteger contra perda de pacotes. Os Restart contador decrementado cada vez que um Configure-Request enviado. Envie-Configure-Ack (SCA) Um pacote Configure-ACK transmitido. Este reconhece o recepo de um pacote Configure-Pedido com um conjunto aceitvel de Opes de configurao. Envie-Configure-Nak (SCN) A Configure-Nak ou Configure-Rejeitar pacote transmitido, como

apropriado. Esta resposta negativa relata a recepo de um

Simpson [Pgina 22]

RFC 1661 Point-to-Point Protocol julho 1994 Configure-Pedido pacote com um conjunto inaceitvel de Configurao Opes. Configure-Nak pacotes so utilizados para recusar uma opo de configurao valor, e sugerir um valor, de novo aceitvel. Configure-Reject pacotes so utilizados para recusar qualquer negociao sobre a configurao de uma Opo, normalmente porque ele no reconhecido ou implementadas. O uso de Configure-Nak contra Configure-Rejeitar mais completa descrito no captulo sobre formatos de pacotes LCP. Envie-Finaliza-Request (str) Um pacote Terminate-Request transmitida. Isto indica que o desejo de fechar uma conexo. Reinicie o temporizador iniciado quando o pacote Finaliza-Pedido transmitida, para proteger contra perda de pacotes. A Restart contador decrementado cada vez que um Terminate-Request enviado. Envie-Finaliza-ACK (sta) Um pacote Finaliza-ACK transmitido. Este reconhece o recepo de um pacote de solicitao de Terminate ou de outra forma serve para sincronizar os autmatos. Enviar Cdigo-Rejeitar (scj) Um pacote de cdigo-Rejeitar transmitida. Isto indica a recepo de um tipo desconhecido de pacote. Enviar-Echo-Reply (SER) Um pacote Echo Reply transmitida. Este reconhece o recepo de um pacote Echo Request.

4,5. Preveno de Loop O protocolo faz uma tentativa razovel de evitar Configurao Loops de negociao de opes. No entanto, o protocolo no garante loops que no vai acontecer. Tal como acontece com qualquer negociao, possvel configurar duas implementaes de PPP com polticas conflitantes que nunca convergem. Tambm possvel configurar polticas que convergem, mas que tenham um tempo significativo para o fazer. Os implementadores deve manter isso em mente e devem implementar deteco de loop mecanismos ou timeouts de nvel superior.

Simpson [Pgina 23]

RFC 1661 Point-to-Point Protocol julho 1994 4,6. Contadores e temporizadores Reinicie o temporizador Existe um temporizador especial usado pelo autmato. Os Restart timer usado para transmisses de tempo de Configure-Request e Encerrar Pedido de pacotes. Validade das causas Restart temporizador um evento de tempo limite, e retransmisso do correspondente Configure-Request ou Terminate-Request packet. Reinicie o timer Deve ser configurvel, mas deve usar como padro para trs (3) segundos. Nota de Implementao: O temporizador restart devem basear-se na velocidade da ligao. O valor padro projetado para baixa velocidade (2.400 para 9.600 bps), de alta latncia de comutao ligaes (linhas telefnicas comuns). Ligaes de maior velocidade, ou links com latncia de comutao baixa, deve tm tempos de retransmisso correspondentemente mais rpidos. Em vez de um valor constante, o temporizador de reinicializao pode comear em uma pequeno valor inicial e aumento para o valor configurado final. Cada valor sucessivo menor que o valor final deve estar no pelo menos duas vezes o valor anterior. O valor inicial deve ser suficientemente grande para explicar o tamanho dos pacotes, o dobro do completam tempo de viagem para a transmisso na velocidade da conexo, e em menos um adicional de 100 milissegundos para permitir que o peer-toprocessar os pacotes antes de responder. Alguns circuitos adicionar mais 200 milsimos de segundo de atraso por satlite. Round trip vezes para modems que operam a 14.400 bps foram medidos no gama de 160 a mais de 600 milissegundos. Max-Encerrar No necessrio reiniciar um contador para encerr-Requests. Max-Finaliza indica o nmero de Terminar Pedido de pacotes enviados sem receber um Finaliza-ACK antes assumindo que o pares incapaz de responder. Max-Terminate deve ser configurvel, mas deve usar como padro para dois (2) transmisses. Max-Configurar Um contador semelhante recomendado para Configure-Os pedidos. Max-

Configurar indica o nmero de Configurar Pedido de pacotes enviados sem receber um vlido Configure-ACK, Configure-Nak ou Configure-Rejeitar antes de assumir que o ponto incapaz de responder. Max-Configurar deve ser configurvel, mas deve usar como padro a 10 (10) transmisses.

Simpson [Pgina 24]

RFC 1661 Point-to-Point Protocol julho 1994 Max-falha Um contador relacionado recomendado para Configure-Nak. Maxfalha indica o nmero de Configure-Nak pacotes enviados sem enviar uma Configure-ACK antes assumindo que a configurao no convergentes. Quaisquer outras Configure-Nak pacotes para pares solicitado opes forem convertidas configurar-rejeitar pacotes, e localmente opes desejadas no so mais anexado. Max-falha deve ser configurvel, mas deve usar como padro a cinco (5) as transmisses.

Simpson [Pgina 25]

RFC 1661 Point-to-Point Protocol julho 1994 5. Formatos de pacotes LCP H trs classes de pacotes LCP: 1. Link pacotes de configurao utilizados para criar e configurar um link (Configure-Request, Configure-ACK, Configure-Nak e Configure-Reject). 2. Link pacotes de Terminao usados para terminar a ligao (TerminatePedidos e encerr-ACK). 3. Link pacotes de manuteno utilizados para gerir e depurar um link (Cdigo-Rejeitar, Protocolo-Rejeitar, Echo Request, Echo Reply-e Discard-Request). No interesse da simplicidade, no h nenhum campo de verso no LCP pacote. A aplicao funcionando corretamente LCP ser sempre responder a protocolos e cdigos desconhecidos com um facilmente reconhecvel LCP pacote, proporcionando um mecanismo determinista alternativa para implementaes de outras verses. Independentemente do que opes de configurao so habilitados, Link todos LCP Configurao Link Resciso e Cdigo-Rejeitar pacotes (cdigos 1 a 7) so sempre enviadas como se h opes de configurao foram negociado. Em particular, cada opo configurao especifica uma valor padro. Isso assegura que os pacotes LCP tais so sempre reconhecvel, mesmo quando uma extremidade da ligao erroneamente acredita que o vincular a ser aberto. Exatamente um pacote LCP encapsulado no campo Informaes PPP, onde o protocolo PPP campo indica tipo hex C021 (Link Control Protocol). Um resumo da ligao formato do pacote Protocolo de Controle de mostrado abaixo. Os campos so transmitidos da esquerda para a direita. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Cdigo | Identificador | Tamanho | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Dados ... + - + - + - + - + Cdigo

O campo Cdigo um octeto, e identifica o tipo de LCP

Simpson [Pgina 26]

RFC 1661 Point-to-Point Protocol julho 1994 pacote. Quando um pacote recebido com um campo de cdigo desconhecida, uma Cdigo-Rejeitar pacote transmitido. Up-to-date valores do campo Cdigo LCP so especificados na maioria recentes "Assigned Numbers" RFC [2]. Este documento diz respeito a seguintes valores: 1 Configure-Request 2 Configure-Ack 3 Configure-Nak 4 Configure-Reject 5 Terminate-Request 6 Finaliza-ACK 7 Cdigo-Rejeitar 8 Protocolo-Rejeitar 9 Echo Request10 Echo-Responder 11 Discard-Request Identificador O campo identificador um octeto, e auxilia nos pedidos correspondentes e as respostas. Quando um pacote recebido com um identificador invlido campo, o pacote descartado silenciosamente sem afetar o autmato. Comprimento O campo Comprimento dois octetos, e indica o comprimento do LCP pacote, incluindo o cdigo, Identificador, Comprimento e Dados campos. O comprimento no deve exceder a MRU do link. Octetos fora do intervalo de campo Comprimento so tratados como preenchimento e so ignorados na recepo. Quando um pacote recebido com um campo de comprimento invlido, o pacote descartado silenciosamente sem afetar o autmato. Dados O campo de dados zero ou mais octetos, como indicado pelo comprimento campo. O formato do campo de dados determinado pelo Cdigo campo.

Simpson [Pgina 27]

RFC 1661 Point-to-Point Protocol julho 1994 5,1. Configure-Request Descrio Uma implementao que pretenda abrir uma conexo deve transmitir um Configure-Request. O campo Opes preenchido com qualquer desejado mudanas nos padres de ligao. Opes de configurao no deve ser includo com valores padro. Aquando da recepo de um Configure-Request, uma resposta apropriada deve ser transmitido. Um resumo do formato do pacote Configure-Pedido mostrado abaixo. O campos so transmitidos da esquerda para a direita. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Cdigo | Identificador | Tamanho | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Opes ... + - + - + - + - + Cdigo 1 para Configure-Request. Identificador O campo identificador deve ser mudado, sempre que o contedo do Opes das mudanas de campo, e sempre que uma resposta vlida foi recebida por um pedido anterior. Para as retransmisses, o Identificador pode permanecer inalterada. Opes O campo de opes varivel de comprimento, e contm a lista de zero ou mais opes de configurao que o remetente deseje negociar. Todas as opes de configurao so sempre negociados simultaneamente. O formato das opes de configurao mais descrita em um captulo posterior.

Simpson [Pgina 28]

RFC 1661 Point-to-Point Protocol julho 1994 5,2. Configure-Ack Descrio Se todas as opes de configurao recebidas em um ConfigureRequest valores reconhecveis e todos so aceitveis, em seguida, o implementao deve transmitir uma Configure-Ack. O reconhecido Opes de configurao NO DEVE ser reordenados ou modificada em qualquer caminho. Na recepo de um Configure-Ack, o campo identificador deve corresponder que da ltima transmitida Configure-Request. Alm disso, o Opes de configurao em um Configure-Ack deve corresponder exatamente aqueles da ltima transmitida Configure-Request. Pacotes invlidos so silenciosamente descartado. Um resumo do formato do pacote Configurar ACK mostrado abaixo. O campos so transmitidos da esquerda para a direita. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Cdigo | Identificador | Tamanho | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Opes ... + - + - + - + - + Cdigo 2 para Configure-ACK. Identificador O campo identificador uma cpia do identificador do campo Configure-Pedido que causou este Configure-Ack. Opes O campo Opes varivel de comprimento, e contm a lista de zero ou mais opes de configurao que o remetente reconhecendo. Todas as opes de configurao so sempre reconheceu simultaneamente.

Simpson [Pgina 29]

RFC 1661 Point-to-Point Protocol julho 1994 5,3. Configure-Nak Descrio Se todas as instncias das opes de configurao recebidas reconhecvel, mas alguns valores no so aceitveis, em seguida, o implementao deve transmitir uma Configure-Nak. O campo Opes preenchido apenas com as opes de configurao inaceitveis de o Configure-Request. Todas as opes de configurao so aceitveis filtrada para fora do Configure-Nak, mas por outro lado a configurao do Opes da Configure-Pedido no deve ser reordenadas. Opes que no tm campos de valores (opes booleanos) devem usar o Configure-Rejeitar responder em seu lugar. Cada opo de configurao que permitido apenas uma nica instncia Deve ser modificado para um valor aceitvel para a Configure-Nak remetente. O valor padro pode ser utilizado, quando o que difere da solicitado valor. Quando um tipo particular de opo de configurao pode ser listado mais de uma vez com valores diferentes, o Configure-Nak deve incluir um lista de todos os valores para que a opo que so aceitveis para o Configure-Nak remetente. Isto inclui valores aceitveis que eram presentes no Configure-Request. Finalmente, uma implementao pode ser configurado para solicitar o negociao de uma opo de configurao especfica. Se essa opo no listado, essa opo pode ser acrescentada lista de Nak'd Opes de configurao, a fim de solicitar o peer para incluir esse opo em seu pacote Configure-Pedido seguinte. Os campos de valor para A opo deve indicar valores aceitveis para o Configure-Nak remetente. Na recepo de um Configure-Nak, o campo identificador deve corresponder que da ltima transmitida Configure-Request. Pacotes invlidos so silenciosamente descartados. Recepo de um vlido Configure-Nak indica que quando um novo Configure-Request enviado, as opes de configurao podem ser modificado tal como especificado no Configure-Nak. Quando mltiplos

instncias de uma opo de configurao esto presentes, a arbitragem deve selecionar um nico valor para incluir no seu prximo ConfigureRequest pacote. Algumas opes de configurao tem um comprimento varivel. Uma vez que o Opo Nak'd foi modificado pelos pares, a implementao Deve ser capaz de lidar com um comprimento de Opo que diferente do

Simpson [Pgina 30]

RFC 1661 Point-to-Point Protocol julho 1994 o original Configure-Request. Um resumo do formato do pacote Configure-Nak mostrado abaixo. O campos so transmitidos da esquerda para a direita. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Cdigo | Identificador | Tamanho | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Opes ... + - + - + - + - + Cdigo 3 para Configure-Nak. Identificador O campo identificador uma cpia do identificador do campo Configure-Pedido que causou este Configure-Nak. Opes O campo Opes varivel de comprimento, e contm a lista de zero ou mais opes de configurao que o remetente est Nak'ing. Todas as opes de configurao so sempre Nak'd simultaneamente.

5,4. Configure-Reject Descrio Se algumas opes de configurao recebidas em um ConfigureRequest so no reconhecvel ou no so aceitveis para a negociao (como configurados por um administrador de rede), ento a implementao do Deve transmitir um Configure-Rejeitar. O campo Opes est cheio apenas com as opes de configurao inaceitveis do Configure-Request. Toda a configurao reconhecvel e negocivel Opes so filtrados da Configure-Rejeitar, mas de outra forma as opes de configurao NO DEVE ser reordenados ou modificada em qualquer caminho. Na recepo de um Configure-Rejeitar, no campo identificador deve coincidir com o ltimo transmitido Configure-Request. Alm disso, as opes de configurao em uma Configure-Rejeitar MUST

Simpson [Pgina 31]

RFC 1661 Point-to-Point Protocol julho 1994 ser um subconjunto adequado dos que esto no ltimo transmitido ConfigurePedido. Invlido pacotes so silenciosamente descartados. Recepo de um vlido Configure-Rejeitar indica que quando um novo Configure-Request enviado, no deve incluir qualquer um dos Opes de configurao listado no Configure-Rejeitar. Um resumo do formato do pacote Configurar-Rejeitar mostrado abaixo. O campos so transmitidos da esquerda para a direita. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Cdigo | Identificador | Tamanho | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Opes ... + - + - + - + - + Cdigo 4 para Configure-Rejeitar. Identificador O campo identificador uma cpia do identificador do campo Configure-Pedido que causou este Configure-Rejeitar. Opes O campo Opes varivel de comprimento, e contm a lista de zero ou mais opes de configurao que o remetente est rejeitando. Todas as opes de configurao so sempre rejeitados simultaneamente.

Simpson [Pgina 32]

RFC 1661 Point-to-Point Protocol julho 1994 5,5. Finaliza-Pedidos e encerr-ACK Descrio LCP inclui Finaliza-Pedidos e encerr-ACK Cdigos, a fim de proporcionar um mecanismo para fechar uma conexo. Uma implementao que desejam fechar uma conexo deve transmitir uma Terminate-Request. Encerrar Pedido de pacotes deve continuar a ser enviadas at Finaliza-ACK recebido, a camada inferior indica que tem ido para baixo, ou um nmero suficientemente grande ter sido transmitida de tal forma que o par est em baixo, com razovel certeza. Aps a recepo de uma Finaliza-Request, um Finaliza-ACK deve ser transmitida. Recepo de um unelicited Finaliza-ACK indica que os pares nos estados de defeso ou parado, ou em qualquer outra necessidade de renegociao. Um resumo do Finaliza-Pedidos e formatos Finaliza-ACK mostrado abaixo. Os campos so transmitidos da esquerda para a direita. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Cdigo | Identificador | Tamanho | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Dados ... + - + - + - + - + Cdigo 5 para Terminate-Request; 6 para Finaliza-ACK. Identificador Na transmisso, o campo identificador deve ser alterado sempre que o contedo das mudanas campo de dados, e sempre tem uma resposta vlida foi recebido por um pedido anterior. Para as retransmisses, o Identificador pode permanecer inalterada. Na recepo, o identificador do campo Terminate-Request copiado para o campo identificador do pacote Finaliza-ACK.

Simpson [Pgina 33]

RFC 1661 Point-to-Point Protocol julho 1994 Dados O campo de dados zero ou mais octetos, e contm uninterpreted dados para uso pelo remetente. Os dados podem ser constitudas por qualquer binrio valor. O final do campo indicado pelo comprimento.

5,6. Cdigo-Rejeitar Descrio A recepo de um pacote de LCP com um cdigo indica que o desconhecido pares est operando com uma verso diferente. Esta deve ser comunicada de volta ao remetente do Cdigo desconhecido, transmitindo um cdigoRejeitar. Aps a recepo do Cdigo-Rejeitar de um cdigo que fundamental para esta verso do protocolo, a execuo dever informar o problema e soltar a ligao, uma vez que improvvel que o situao pode ser corrigida automaticamente. Um resumo do formato de cdigo-Rejeitar pacote mostrado abaixo. O campos so transmitidos da esquerda para a direita. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Cdigo | Identificador | Tamanho | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Rejeitado Packet-... + - + - + - + - + - + - + - + - + Cdigo 7 para Cdigo-Rejeitar. Identificador O campo identificador deve ser alterado para cada CdigoRejeitar enviada. Rejeitado PacketO campo Rejeitada Packet contm uma cpia do pacote LCP que est sendo rejeitado. Ela comea com o campo da Informao, e faz no incluir todos os dados cabealhos Link Layer nem um FCS. O Rejeitado por pacotes deve ser truncado para dar cumprimento ao ponto de

Simpson [Pgina 34]

RFC 1661 Point-to-Point Protocol julho 1994 estabelecido MRU.

5,7. Protocolo-Rejeitar Descrio Recepo de um pacote PPP com um campo protocolo indica desconhecido que o par est tentando usar um protocolo que sem suporte. Isso geralmente ocorre quando um ponto tenta configurar um novo protocolo. Se o autmato LCP est no Aberto estado, ento esta deve ser comunicada de volta para o ponto de transmisso um Protocolo-Rejeitar. Aquando da recepo de um Protocolo-Rejeitar, a execuo deve parar envio de pacotes do protocolo indicado no mnimo oportunidade. Protocolo-Rejeitar pacotes s podem ser enviadas no LCP Inaugurado estado. Protocolo-Rejeitar pacotes recebidos em qualquer outro estado do que o LCP Inaugurado Estado deve ser descartado silenciosamente. Um resumo do formato Protocolo-Rejeitar pacote mostrado abaixo. O campos so transmitidos da esquerda para a direita. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Cdigo | Identificador | Tamanho | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Rejeitado-Protocolo | Rejeitado Informao-... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + Cdigo 8 para Protocol-Reject. Identificador O campo identificador deve ser alterado para cada ProtocoloRejeitar enviada. Rejeitado-Protocolo O campo Rejeitado o protocolo de dois octetos, e contm o PPP Campo protocolo do pacote que est sendo rejeitado.

Simpson [Pgina 35]

RFC 1661 Point-to-Point Protocol julho 1994 Rejeitado InformaoO campo de informao Rejeitada contm uma cpia do pacote que est sendo rejeitado. Ela comea com o campo da Informao, e faz no incluir todos os dados cabealhos Link Layer nem um FCS. O Rejeitado Informao-deve ser truncado para dar cumprimento ao ponto de estabelecido MRU.

5,8. Echo Request e Echo ReplyDescrio LCP inclui Echo Request e Echo Reply-Codes, a fim de fornecer Um link de dados mecanismo de auto-retorno Camada para uso no exerccio tanto sentidos da ligao. Isso til como um auxlio na depurao, determinao ligao de qualidade, testes de desempenho, e por numerosas outras funes. Aps a recepo de uma solicitao de eco-no LCP Inaugurado estado, uma Echo-Responder deve ser transmitida. Pacotes echo-request e Echo Reply-s deve ser enviado no LCP Inaugurado estado. Pacotes echo-request e Echo Reply-recebido em qualquer outro estado do que o estado LCP abertos devem ser silenciosamente descartado. Um resumo do Echo Request e formatos de resposta de eco-pacote mostrado abaixo. Os campos so transmitidos da esquerda para a direita. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Cdigo | Identificador | Tamanho | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Magic Number-| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Dados ... + - + - + - + - + Cdigo 9 para echo-request;

10 para Echo Reply.

Simpson [Pgina 36]

RFC 1661 Point-to-Point Protocol julho 1994 Identificador Na transmisso, o campo identificador deve ser alterado sempre que o contedo das mudanas campo de dados, e sempre tem uma resposta vlida foi recebido por um pedido anterior. Para as retransmisses, o Identificador pode permanecer inalterada. Na recepo, o identificador do campo echo-request copiado no campo Identificador do pacote Echo Reply. Nmero mgicoO campo nmero mgico quatro octetos, e auxilia na deteco de ligaes as quais esto na condio anelada-back. At o nmero mgicoOpo de configurao foi negociado com sucesso, o MagicNmero deve ser transmitida como zero. Veja o nmero mgicoOpo de configurao para mais explicaes. Dados O campo de dados zero ou mais octetos, e contm uninterpreted dados para uso pelo remetente. Os dados podem ser constitudas por qualquer binrio valor. O final do campo indicado pelo comprimento.

5,9. Discard-Request Descrio LCP inclui um Cdigo Descartar-Pedido de modo a proporcionar a Os dados Link mecanismo pia Camada para uso no exerccio do local para direo remota do link. Isto til como uma ajuda na depurao, testes de desempenho, e para inmeras outras funes. Descartar Pedido de pacotes deve ser enviado no estado Inaugurado LCP. Na recepo, o receptor deve silenciosamente descartar qualquer DescartarSolicite que ele recebe.

Simpson [Pgina 37]

RFC 1661 Point-to-Point Protocol julho 1994 Um resumo do formato do pacote de solicitao de Descartar mostrado abaixo. O campos so transmitidos da esquerda para a direita. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Cdigo | Identificador | Tamanho | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Magic Number-| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Dados ... + - + - + - + - + Cdigo 11 para Discard-Request. Identificador O campo identificador deve ser alterado para cada DiscardRequest enviada. Nmero mgicoO campo nmero mgico quatro octetos, e auxilia na deteco de ligaes as quais esto na condio anelada-back. At o nmero mgicoOpo de configurao foi negociado com sucesso, o MagicNmero deve ser transmitida como zero. Veja o nmero mgicoOpo de configurao para mais explicaes. Dados O campo de dados zero ou mais octetos, e contm uninterpreted dados para uso pelo remetente. Os dados podem ser constitudas por qualquer binrio valor. O final do campo indicado pelo comprimento.

Simpson [Pgina 38]

RFC 1661 Point-to-Point Protocol julho 1994 6. Opes de configurao LCP Opes de configurao LCP permitir a negociao das alteraes ao caractersticas padro de um link ponto-a-ponto. Se a configurao de uma Opo no est includa em um pacote Configure-Request, o padro valor para essa opo de configurao assumida. Algumas opes de configurao podem ser listadas mais de uma vez. O efeito deste especfico opo de configurao, e especificado por cada Opo Descrio tal configurao. (Nenhum dos Configurao Opes de presente especificao pode ser listado mais de uma vez.) O final da lista de opes de configurao indicada pelo Campo de comprimento do pacote LCP. Salvo disposio em contrrio, todas as opes de configurao se aplica em um semi-duplex moda; tipicamente, no sentido de receber a ligao a partir do ponto de vista do remetente Configure-Pedido. Filosofia de Design As opes indicam capacidades adicionais ou exigncias de a aplicao que est solicitando a opo. Um implementao que no entender qualquer opo deve interoperar com um que implementa todas as opes. Um padro especificado para cada opo que permite que o link corretamente funcionar sem a negociao da opo, embora talvez com menos de um timo desempenho. Exceto quando explicitamente especificado reconhecimento, de uma opo no requer o ponto de tomar qualquer medida adicional alm do o padro. No necessrio enviar os valores padro para as opes uma Configure-Request. Um resumo do formato opo de configurao mostrada abaixo. O campos so transmitidos da esquerda para a direita. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + | Tipo | Tamanho | Dados ... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - +

Simpson [Pgina 39]

RFC 1661 Point-to-Point Protocol julho 1994 Tipo O campo Tipo um octeto, e indica o tipo de Opo de configurao. Up-to-date valores do tipo de opo LCP campo so especificados no mais recente "Assigned Numbers" RFC [2]. Este documento refere-se aos seguintes valores: 0 1 3 4 5 7 8 RESERVADO Mximo-receber-Unit Authentication ProtocolQualidade Protocolonmero mgicoProtocolo Campo-Compresso Endereo de e-Control-Campo-Compresso

Comprimento O campo Comprimento um octeto, e indica o comprimento desta Opo de configurao, incluindo os campos de comprimento do tipo, e de dados. Se uma opo de configurao negocivel recebido em uma ConfigurePedido, mas com um comprimento invlido ou no reconhecido, uma ConfigureNAK deve ser transmitida, que inclui a configurao desejada Opo com um comprimento adequado e de dados. Dados O campo de dados zero ou mais octetos, e contm informaes especfico para a opo de configurao. O formato e comprimento de o campo de dados determinada pelo tipo e comprimento campos. Quando o campo de dados indicado pelo comprimento para estender para alm no final do campo de informao, todo o pacote silenciosamente descartados sem afetar o autmato.

Simpson [Pgina 40]

RFC 1661 Point-to-Point Protocol julho 1994 6,1. Mximo-receber-Unit (MRU) Descrio Esta opo Configurao pode ser enviada para informar o ponto que o implementao pode receber pacotes maiores, ou para solicitar que o peer enviar pacotes menores. O valor padro 1500 octetos. Se os pacotes so menores solicitado, a implementao deve ainda ser capaz de receber o 1500 campo de informao completa octeto de sincronizao do link caso perdido. Nota de Implementao: Esta opo usada para indicar uma capacidade de implementao. O ponto no necessria para maximizar o uso da capacidade. Por exemplo, quando um MRU indicado que de 2048 octetos, os pares no obrigado a enviar qualquer pacote com 2048 octetos. O pares no precisa Configure-Nak para indicar que ela s vai enviar pacotes menores, desde a implementao exigir sempre suporte para pelo menos 1500 octetos. Um resumo da Opo formato mximo de recebimento Unit-A configurao mostrados abaixo. Os campos so transmitidos da esquerda para a direita. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Tipo | Tamanho | Maximum-Receber-Unit | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + Tipo 1 Comprimento 4 Mximo-receber-Unit O campo Maximum-receber unidade de dois octetos, e especifica o nmero mximo de octetos nas reas de informao e Padding. Ele no inclui a definio, o campo protocolo, FCS, nem qualquer

pedaos de transparncia ou bytes.

Simpson [Pgina 41]

RFC 1661 Point-to-Point Protocol julho 1994 6,2. Authentication ProtocolDescrio Em algumas ligaes, pode ser desejvel para exigir um peer para se autenticar antes de permitir que os pacotes de rede protocolo de camada de para ser trocado. Esta opo Configurao fornece um mtodo para negociar o uso de um protocolo especfico para autenticao. Por padro, autenticao no necessria. Uma implementao no deve incluir autenticao de mltiplos Opes de configurao de protocolo em suas Configurar Pedido de pacotes. Em vez disso, ele deve tentar configurar o mais desejvel primeiro protocolo. Se esse protocolo configurar-Nak'd, ento o implementao deve tentar o prximo protocolo mais desejvel em o prximo Configure-Request. A implementao de enviar o Configure-Pedido est indicando que espera que a autenticao de seus pares. Se um aplicao envia uma Configure-ACK, ento ele est concordando com autenticar com o protocolo especificado. Uma implementao receber uma Configure-ACK devem esperar que o peer para autenticar com o protocolo reconhecido. No h nenhuma exigncia de que a autenticao ser full-duplex ou que o mesmo protocolo ser usado em ambas as direces. perfeitamente aceitvel para protocolos diferentes para serem usados em cada direco. Isto ir, claro, depender dos protocolos especficos negociadas. Um resumo da Opo formato Authentication Protocol-Configurao mostrado abaixo. Os campos so transmitidos da esquerda para a direita. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Tipo | Tamanho | Authentication Protocol-| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Dados ... + - + - + - + - + Tipo 3

Simpson [Pgina 42]

RFC 1661 Point-to-Point Protocol julho 1994 Comprimento > = 4 Authentication ProtocolO campo Authentication Protocol- de dois octetos, e indica o protocolo de autenticao desejada. Os valores para este campo so sempre o mesmo que o campo de protocolo PPP valores para que mesmo protocolo de autenticao. Up-to-date valores do campo Authentication Protocol-se especificado no mais recente "Assigned Numbers" RFC [2]. Atual Os valores so designados como segue: Valor (em hexadecimal) Protocolo c023 Password Authentication Protocol C223 Challenge Handshake Authentication Protocol Dados O campo de dados zero ou mais octetos, e contm informaes adicionais dados, tal como determinado pelo protocolo particular.

6,3. Qualidade ProtocoloDescrio Em algumas ligaes, pode ser desejvel para determinar quando e como muitas vezes, o link est caindo de dados. Este processo chamado de ligao monitoramento da qualidade. Esta opo Configurao fornece um mtodo para negociar o uso de um protocolo especfico para a monitorizao da qualidade do link. Por padro, monitoramento da qualidade da ligao est desativado. A implementao de enviar o Configure-Pedido est indicando que espera receber informaes sobre o acompanhamento de seus pares. Se uma aplicao envia uma Configure-ACK, ento ele est concordando com enviar o protocolo especificado. Uma implementao de receber uma Configure-ACK devem esperar os pares de enviar o reconhecido protocolo. No h exigncia de que o controlo da qualidade ser full-duplex ou

Simpson [Pgina 43]

RFC 1661 Point-to-Point Protocol julho 1994 que o mesmo protocolo ser usado em ambas as direces. perfeitamente aceitvel para protocolos diferentes para ser utilizado em cada direo. Isto ir, claro, depender dos protocolos especficos negociado. Um resumo do formato de Opo de Qualidade Protocolo-configurao mostrados abaixo. Os campos so transmitidos da esquerda para a direita. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Tipo | Tamanho | Qualidade Protocolo-| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Dados ... + - + - + - + - + Tipo 4 Comprimento > = 4 Qualidade ProtocoloO campo de Qualidade Protocolo de dois octetos, e indica o link protocolo de monitoramento da qualidade desejada. Os valores para este campo so sempre o mesmo que os valores protocolo PPP campo para que mesmo controlo de protocolo. Up-to-date valores do campo Qualidade protocolo encontram-se especificados no mais recente "Assigned Numbers" RFC [2]. Os valores atuais so atribudo como se segue: Valor (em hexadecimal) Protocolo C025 Relatrio Link Quality Dados O campo de dados zero ou mais octetos, e contm informaes adicionais dados, tal como determinado pelo protocolo particular.

Simpson [Pgina 44]

RFC 1661 Point-to-Point Protocol julho 1994 6,4. Nmero mgicoDescrio Esta opo Configurao fornece um mtodo para detectar loopback links e outros dados anomalias camada de ligao. Esta configurao Opo poder ser exigida por algumas outras opes de configurao, tais como Opo de configurao de qualidade de Protocolo. Por padro, o Nmero mgico, no negociado, e zero inserido em um Nmero mgico, de outro modo poderiam ser usados. Antes desta opo de configurao solicitado, a implementao de um Deve escolher o seu nmero mgico. Recomenda-se que o-Magic Nmero ser escolhido de forma mais aleatria possvel, a fim de garantir com probabilidade muito alta de que uma aplicao ir chegar a um nmero nico. Uma boa maneira de escolher um nico aleatria nmero comear com uma semente nica. Fontes sugeridas de singularidade incluir nmeros de srie da mquina e outro hardware de rede endereos, tempo de dia relgios, etc Particularmente bom aleatria sementes nmero so medies precisas do tempo entre chegadas de eventos fsicos, tais como recepo de pacotes em outro ligado redes, tempo de resposta do servidor, ou a taxa de digitao de um ser humano usurio. Tambm sugerido que as fontes como o maior nmero possvel ser utilizados simultaneamente. Quando um Configure-Request recebido com um nmero mgicoOpo de configurao, recebeu o nmero mgico- comparado com o nmero mgico do ltimo Configure-Pedido enviado para o ponto. Se os dois Mgicos Os nmeros so diferentes, ento o link no loop-back, eo nmero mgico-deve ser reconhecido. Se o dois nmeros de magia so iguais, ento possvel, mas no certo, que o link est em loop-back e que este Configure-Pedido realmente o ltimo enviado. Para determinar isso, uma ConfigureNak Deve ser enviada especificando um valor nmero mgico-diferente. Um novo Configure-Pedido no deve ser enviado para o ponto at normal, processamento faria com que ele ser enviado (isto , at que um ConfigureNak recebido ou Reinicie o temporizador se esgota). Recepo de uma Configure-Nak com um nmero mgico, diferente de que da ltima Configure-Nak enviado para o ponto prova que um link no em loop-back, e indica um nico nmero mgico. Se o Nmero mgico igual ao enviado na ltima Configure-Nak, a possibilidade de uma ligao em lao-back aumentada, e um novo

Nmero mgico, deve ser escolhido. Em qualquer caso, uma nova ConfigurarPedido deve ser enviado com o novo nmero mgico. Se a ligao for de fato em loop-back, essa sequncia (transmisso Configure-Request, receber Configure-Request, transmitir Configure-

Simpson [Pgina 45]

RFC 1661 Point-to-Point Protocol julho 1994 Nak, receber Configure-Nak) vai repetir uma e outra vez. Se o link no est em loop-back, essa sequncia pode ocorrer alguns vezes, mas extremamente improvvel que ocorra repetidamente. Mais provavelmente, os nmeros de magia escolhida em cada extremidade ser rapidamente divergem, que encerra a seqncia. A tabela seguinte mostra o probabilidade de colises assumindo que ambas as extremidades da ligao selecione Magic-nmeros com uma distribuio perfeitamente uniforme: Nmero de Probabilidade Colises ----------------------------------------1 1/2 ** 32 = 2,3 E-10 2 1/2 ** 32 ** 2 = 5,4 E-20 3 1/2 ** 32 ** 3 = 1,3 E-29 Boas fontes de singularidade ou aleatoriedade so necessrios para este divergncia para ocorrer. Se uma boa fonte de singularidade no pode ser encontrados, recomenda-se que no esta opo de configurao ser habilitado; Configure-Os pedidos com a opo no deve ser transmitida e quaisquer Opes de Magic-Nmero de configurao que o peer envia ou deveria ser reconhecido ou rejeitado. Neste caso, em loop-back links no podem ser confiavelmente detectado pelo implementao, embora possam ainda ser detectvel pelos pares. Se uma aplicao no transmitir uma Configure-Request com um Nmero mgico-opo de configurao, ento ele no deve responder com um Configure-Rejeitar quando recebe uma Configure-Request com um Nmero mgico-opo de configurao. Isto , se uma aplicao desejos de usar Magic Numbers, ento ele tambm deve permitir a sua peer to faz-lo. Se uma aplicao no receber uma Configure-Rejeitar no resposta a uma Configure-Request, isso s pode significar que o link no em loop-back, e que seus pares no estar usando-Magia Nmeros. Neste caso, uma aplicao deve actuar como se o negociao tinha sido bem sucedido (como se tivesse recebido uma vez Configure-ACK). O Magic-Nmero tambm pode ser usado para detectar loop-back ligaes durante a operao normal, bem como durante a opo de configurao negociao. Todos LCP echo-request, Echo Reply-, e descartarPedido pacotes tm um campo de nmero mgico. Se nmero mgico tem foi negociado com sucesso, uma implementao deve transmitir esses pacotes com o campo nmero mgico-definido para a sua negociao

Nmero mgico. O campo nmero mgico de estes pacotes devem ser inspecionados em recepo. Todos os recebidos nmero mgico de campos deve ser igual a zero ou o ponto do nico nmero mgico, dependendo ou no o ponto negociou um nmero mgico.

Simpson [Pgina 46]

RFC 1661 Point-to-Point Protocol julho 1994 Recepo de um campo de nmero mgico, igual ao local negociada Nmero mgico, indica um link em loop-back. Recepo de um MagicNmero diferente do negociado local, nmero mgico, o de pares negociado nmero mgico, ou zero se o ponto no negociar um, indica um link que tem sido (mal) configurado para as comunicaes com um par diferente. Procedimentos para a recuperao de ambos os casos no so especificadas, e pode variar de implementao para implementao. Um pouco procedimento pessimista assumir uma LCP de Down evento. Um outro Evento aberto comear o processo de re-estabelecer a ligao, que no pode ser concluda at a condio de loop-back encerrado, e Magic-Os nmeros so negociadas com xito. A mais procedimento optimista (no caso de uma ligao em lao-back) comear a transmitir LCP echo-request pacotes at que um adequado Echo Reply recebido, indicando o encerramento do-loop voltar condio. Um resumo do formato Opo mgica-Nmero configurao mostrada abaixo. Os campos so transmitidos da esquerda para a direita. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Tipo | Tamanho | Magic Number+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + Nmero mgico-(cont) | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + Tipo 5 Comprimento 6 Nmero mgicoO campo nmero mgico quatro octetos e indica um nmero que muito provvel que seja nica para uma extremidade da ligao. A Magia Nmero de zero ilegal e deve ser sempre Nak'd, se no rejeitou completamente.

Simpson [Pgina 47]

RFC 1661 Point-to-Point Protocol julho 1994 6,5. Protocolo Campo-Compresso (PFC) Descrio Esta opo Configurao fornece um mtodo para negociar a compresso do campo de protocolo PPP. Por padro, todas implementaes devem transmitir pacotes com dois octeto PPP Protocolo campos. Nmeros de campo PPP Protocolo so escolhidos de tal modo que alguns valores podem ser comprimida em uma forma nica octeto que claramente distinguvel da forma octeto dois. Esta configurao Opo enviada para informar o peer que a implementao pode receber tais campos protocolo nico octeto. Como mencionado anteriormente, o campo de protocolo utiliza uma extenso mecanismo consistente com o mecanismo de extenso ISO 3309 para o Campo de endereo, o bit menos significativo (LSB) de cada octeto usado para indicar a extenso do campo de protocolo. Um binrio de "0" como o LSB indica que o campo continua com o protocolo seguindo octeto. A presena de um binrio "1", como as marcas LSB o ltimo octeto do campo de protocolo. Note-se que qualquer nmero de "0" octetos podem ser anexado ao campo, e ainda indicar o mesmo valor (considerar as duas representaes binrias para 3, 00000011 e 00000000 00000011). Quando se utiliza elos de baixa velocidade, desejvel para conservar a largura de banda enviando como poucos dados redundantes como possvel. O ProtocoloCampo-Compresso Opo de configurao permite que um trade-off entre simplicidade de implementao e eficincia de largura de banda. Se negociado com sucesso, o mecanismo de extenso ISO 3309 pode ser utilizado para comprimir o campo Protocolo para um octeto, em vez de duas. A grande maioria dos pacotes so compressveis, pois os dados protocolos so tipicamente atribudo com valores de campo Protocolo menos que 256. Campos compactados protocolo no deve ser transmitido a menos que este Opo de configurao tiver sido negociado. Quando negociou, PPP implementaes devem aceitar pacotes PPP com um duplo-octeto ou campos de um nico protocolo octeto, e no deve distinguir entre eles.

O protocolo campo nunca comprimida durante o envio de qualquer LCP pacote. Esta regra garante o reconhecimento inequvoco da LCP pacotes. Quando um campo protocolo comprimido, a ligao de dados Camada de campo FCS calculado sobre o quadro de comprimido no, o original

Simpson [Pgina 48]

RFC 1661 Point-to-Point Protocol julho 1994 quadro descompactado. Um resumo da opo Configuration Protocol-Campo-Compresso formato mostrado abaixo. Os campos so transmitidos a partir da esquerda para direito. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Tipo | Tamanho | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + Tipo 7 Comprimento 2

Simpson [Pgina 49]

RFC 1661 Point-to-Point Protocol julho 1994 6,6. Endereo de e-Control-Campo-Compresso (ACFC) Descrio Esta opo Configurao fornece um mtodo para negociar a compresso do endereo da camada Data Link e campos de controle. Por padro, todas as implementaes devem transmitir frames com endereos e Campos de controlo adequados para a elaborao ligao. Uma vez que esses campos geralmente tm valores constantes para ponto-a-ponto ligaes, que so facilmente comprimida. Esta opo de configurao enviado para informar o peer que a implementao pode receber Endereo comprimido e campos de controle. Se um quadro comprimido recebida quando Endereo de e-ControlFieldA compactao no foi negociado, a implementao pode silenciosamente descartar o quadro. Os campos de endereo e de controle no devem ser compactados quando enviar qualquer pacote LCP. Esta regra garante o reconhecimento inequvoco da Pacotes LCP. Quando os campos de endereo e de controle so comprimidas, Link de Dados Camada campo FCS calculado sobre o quadro de comprimido no, o quadro descompactado original. Um resumo da configurao Endereo de e-Control-Campo-Compresso formato opo mostrado abaixo. Os campos so transmitidos a partir da esquerda para a direita. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Tipo | Tamanho | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + Tipo 8 Comprimento 2

Simpson [Pgina 50]

RFC 1661 Point-to-Point Protocol julho 1994 Consideraes de Segurana Questes de segurana so brevemente discutidas nas sees relativas Fase de autenticao, o evento Close, ea Autenticao Protocolo opo de configurao.

Referncias [1] Perkins, D., "Requisitos para um Internet Standard Point-toPoint Protocol ", RFC 1547, Carnegie Mellon University, Dezembro de 1993. [2] Reynolds, J., e Postel, J., "Assigned Numbers", STD 2, RFC 1340, USC / Information Sciences Institute, julho de 1992. Agradecimentos Este documento o produto do Protocolo Ponto-a-Ponto de Trabalho Grupo da Fora Internet Engineering Task Force (IETF). Os comentrios devem ser submetido ao ietf-ppp@merit.edu mailing list. Grande parte do texto no presente documento tomado a partir do grupo de trabalho requisitos [1]; e RFCs 1171 e 1172, por Drew Perkins, enquanto em Carnegie Mellon University, e por Russ Hobby da Universidade de Califrnia, em Davis. William Simpson foi o principal responsvel pela introduo terminologia consistente e filosofia, ea re-design da fase e negociao mquinas de estado. Muitas pessoas passavam tempo significativo ajudando a desenvolver a Point-toProtocolo Ponto. A lista completa das pessoas muito numerosas para listar, mas as seguintes pessoas merecem um agradecimento especial: Rick Adams, Ken Adelman, Fred Baker, Mike Ballard, Craig Fox, Karl Fox, Phill Gross, Kory Hamzeh, o ex-WG cadeira Hobby Russ, David Kaufman, o ex-WG Knowles cadeira Steve, Mark Lewis, o ex-WG cadeira Brian Lloyd, John LoVerso, Bill Melohn, Mike Patton, ex-presidente WG Drew Perkins, Greg Satz, John Shriver, Vernon Schryver, e Aser Waldfogel. Agradecimentos especiais a Morning Star Technologies para fornecer computao recursos e apoio de rede de acesso para escrever esta especificao.

Simpson [Pgina 51]

RFC 1661 Point-to-Point Protocol julho 1994 Endereo do presidente O grupo de trabalho pode ser contactado atravs do atual presidente: Fred Baker Advanced Computer Communications 315 Unidade Bollay Santa Barbara, Califrnia 93117 fbaker@acc.com

Endereo do Editor Dvidas sobre esta nota tambm pode ser dirigida a: William Allen Simpson Daydreamer Sistemas de Computador Servios de Consultoria 1384 Fontaine Madison Heights, Michigan 48071 Bill.Simpson @ um.cc.umich.edu bsimpson@MorningStar.com

Simpson [Pgina 52]