 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
For those who haven’t seen it yet, there’s a proposed
update to RFC-4938: draft-bberry-rfc4938bis-00.txt. One aspect of the
revision (section 3.3) includes adding a Credit TLV to the session protocol packets.
This contradicts my understanding of the original PPPoE specification in
that the TLVs were present in the discovery packets but the session packets
always contain only the PPP packet as a payload. However, in an off-list
conversation with the authors, we couldn’t find anything that made this
clear: the closest I could find was the fact that TLVs are described in the
Discovery Stage of the document (section 5) but not mentioned in the Session
Stage (section 6); further there isn’t any way that one could determine if
the first field after the PPPoE header is a TLV type or a PPP protocol identifier. I’ve gone through the list archives and realize that
the original document wasn’t warmly received. I’d like to
avoid revisiting those arguments and simply raise the question as to whether
TLVs can appear in PPPoE Session packets. If not: what would be a
reasonable alternative: using TLV type codes which correspond to the reserved
PPP protocol values (as per RFC-1661: odd values between 0x0003 and 0x001F along
with 0x00FF)? I’ve suggested appending them to PADQ messages
instead since that’s already a message type that in their document does
not need to be acknowledged but they want to piggyback the TLVs into packets in
flight rather than deal with separate packets. TIA. |
_______________________________________________ Pppext mailing list Pppext at ietf.org https://www.ietf.org/mailman/listinfo/pppext