To provide a point-to-point connection over Ethernet, each PPP session must learn the Ethernet address of the remote peer, as well as establish a unique session identifier. PPPoE includes a discovery protocol that provides this.
PPPoE has two distinct stages. There is a Discovery stage and a PPP Session stage. When a Host wishes to initiate a PPPoE session, it must first perform Discovery to identify the Ethernet MAC address of the peer and establish a PPPoE SESSION_ID. While PPP defines a peer-to-peer relationship, Discovery is inherently a client-server relationship. In the Discovery process, a Host (the client) discovers an Access Concentrator (the server). Based on the network topology, there may be more than one Access Concentrator that the Host can communicate with. The Discovery stage allows the Host to discover all Access Concentrators and then select one. When
Discovery completes successfully, both the Host and the selected Access Concentrator have the information they will use to build their point-to-point connection over Ethernet.The Discovery stage remains stateless until a PPP session is established. Once a PPP session is established, both the Host and the Access Concentrator MUST allocate the resources for a PPP virtual interface.
Discovery Stage
There are four steps to the Discovery stage. When it completes, both peers know the PPPoE SESSION_ID and the peer's Ethernet address, which together define the PPPoE session uniquely. The steps consist of the Host broadcasting an Initiation packet, one or more Access Concentrators sending Offer packets, the Host sending a unicast
Session Request packet and the selected Access Concentrator sending a Confirmation packet. When the Host receives the Confirmation packet, it may proceed to the PPP Session Stage. When the Access Concentrator sends the Confirmation packet, it may proceed to the PPP Session Stage.
All Discovery Ethernet frames have the ETHER_TYPE field set to the value 0x8863.
The PPPoE payload contains zero or more TAGs.
The PPPoE Active Discovery Initiation (PADI) packet
The Host sends the PADI packet with the DESTINATION_ADDR set to the broadcast address. The CODE field is set to 0x09 and the SESSION_ID MUST be set to 0x0000.
The PADI packet MUST contain exactly one TAG of TAG_TYPE Service-Name, indicating the service the Host is requesting, and any number of other TAG types. An entire PADI packet (including the PPPoE header) MUST NOT exceed 1484 octets so as to leave sufficient room for a relay agent to add a Relay-Session-Id TAG.
The PPPoE Active Discovery Offer (PADO) packet
When the Access Concentrator receives a PADI that it can serve, it replies by sending a PADO packet. The DESTINATION_ADDR is the unicast address of the Host that sent the PADI. The CODE field is set to 0x07 and the SESSION_ID MUST be set to 0x0000.The PADO packet MUST contain one AC-Name TAG containing the Access Concentrator's name, a Service-Name TAG identical to the one in the PADI, and any number of other Service-Name TAGs indicating other services that the Access Concentrator offers. If the Access Concentrator can not serve the PADI it MUST NOT respond with a PADO.
The PPPoE Active Discovery Request (PADR) packet
Since the PADI was broadcast, the Host may receive more than one PADO. The Host looks through the PADO packets it receives and chooses one. The choice can be based on the AC-Name or the Services offered. The Host then sends one PADR packet to the Access Concentrator that it has chosen. The DESTINATION_ADDR field is set to the unicast Ethernet address of the Access Concentrator that sent the PADO. The CODE field is set to 0x19 and the SESSION_ID MUST be set to 0x0000.
The PADR packet MUST contain exactly one TAG of TAG_TYPE Service-Name, indicating the service the Host is requesting, and any number of other TAG types.
The PPPoE Active Discovery Session-confirmation (PADS) packet When the Access Concentrator receives a PADR packet, it prepares to begin a PPP session. It generates a unique SESSION_ID for the PPPoE session and replies to the Host with a PADS packet. The DESTINATION_ADDR field is the unicast Ethernet address of the Host that sent the PADR. The CODE field is set to 0x65 and the SESSION_ID
MUST be set to the unique value generated for this PPPoE session.The PADS packet contains exactly one TAG of TAG_TYPE Service-Name,indicating the service under which Access Concentrator has accepted the PPPoE session, and any number of other TAG types.
If the Access Concentrator does not like the Service-Name in the PADR, then it MUST reply with a PADS containing a TAG of TAG_TYPE Service-Name-Error (and any number of other TAG types). In this case the SESSION_ID MUST be set to 0x0000.
The PPPoE Active Discovery Terminate (PADT) packet
This packet may be sent anytime after a session is established to indicate that a PPPoE session has been terminated. It may be sent by either the Host or the Access Concentrator. The DESTINATION_ADDR field is a unicast Ethernet address, the CODE field is set to 0xa7 and the SESSION_ID MUST be set to indicate which session is to be terminated. No TAGs are required. When a PADT is received, no further PPP traffic is allowed to be sent using that session. Even normal PPP termination pckets MUST NOT be sent after sending or receiving a PADT. A PPP peer SHOULD use the
PPP protocol itself to bring down a PPPoE session, but the PADT MAY be used when PPP can not be used.
PPP Session Stage
Once the PPPoE session begins, PPP data is sent as in any other PPP encapsulation. All Ethernet packets are unicast. The ETHER_TYPE field is set to 0x8864. The PPPoE CODE MUST be set to 0x00. The SESSION_ID MUST NOT change for that PPPoE session and MUST be the value assigned in the Discovery stage. The PPPoE payload contains a
PPP frame. The frame begins with the PPP Protocol-ID.
LCP Considerations
The Magic Number LCP configuration option is RECOMMENDED, and the Protocol Field Compression (PFC) option is NOT RECOMMENDED. An implementation MUST NOT request any of the following options, and MUST reject a request for such an option:
Field Check Sequence (FCS) Alternatives,
Address-and-Control-Field-Compression (ACFC),
Asynchronous-Control-Character-Map (ACCM)
The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a larger size than 1492. Since Ethernet has a maximum payload size of 1500 octets, the PPPoE header is 6 octets and the PPP Protocol ID is 2 octets, the PPP MTU MUST NOT be greater than 1492. It is RECOMMENDED that the Access Concentrator ocassionally send Echo-Request packets to the Host to determine the state of the session. Otherwise, if the Host terminates a session without sending a Terminate-Request packet, the Access Concentrator will not be able to determine that the session has gone away.
When LCP terminates, the Host and Access concentrator MUST stop using that PPPoE session. If the Host wishes to start another PPP session,it MUST return to the PPPoE Discovery stage.
Refer:RFC2516
For other tutorials please visit my profile.
1 comment:
Netgear Login is available for those user who really wants help in case of netgear extender and router problems. Our third party technical service team available for instant help. Get in touch with us for emergency help.
https://abbottmichellema.wixsite.com/routerlogin/post/troubleshoot-router-login
https://study.mdanderson.org/eportfolios/2626/Home/Netgear_Router_Not_Connecting_to_the_Internet_What_to_do
http://wifihelp.mystrikingly.com/blog/is-your-router-keeps-dropping-internet
https://wifihelp.weebly.com/
https://www.vingle.net/posts/2746201
http://crweworld.com/usa/ny/new-york/localnews/tech/1420457/a-detailed-guide-to-fix-wifi-keeps-dropping-in-windows-pc
http://abbottmichelle.greatwebsitebuilder.com/
Post a Comment