Re: I-D ACTION:draft-ietf-pppext-pppoe-mtu-1500-00.txt

> From: John Fitzgibbon <[email protected]>

> This is a real problem for me, and it's not performance related -- I have 
> residential DSL service and my provider, SBC, only offer PPPoE, (and they 
> seem *very* reluctant to change). Since I write network test software, the 
> lack of transparency resulting from an MTU of 1492 causes me some headaches. 
> Given that I'm reasonably sure the hardware is capable of handling a 1500 
> byte MTU, the PPPoE limit seems overly restrictive. My thinking was that if I 
> couldn't change SBC, I'd try to change PPPoE. 

Why won't SBC need to change software, firmware or software at their
end to understand new PPPoE tags?

Is there some evidence that SBC's end of your DSL link will pass
frames with 1500 bytes of IP data over the DSL link to your equipment?
For example, have you tried sending UDP or ICMP packets with the
DF bit set toward your home system to see if and where IP fragmentation
happens?

What CPE do you have that will generate or accept new IEEE tags?
Will it send or accept frames containing 1500 bytes of IP data?
If not, do you have firmware or software source for it so that you
can fix it?

Why isn't this effort too little too late?  PPPoE is an incredibly
nasty, amazingly ill considered kludge, but by the time it came to
the IETF, it seened to be set in concrete.

In many markets there are DSL providers that allow or even require
PPPoA instead of PPPoE.  Their services tend to cost more than what
you get from the ILEX, but I think you rarely get more value than what
you pay for.  My DSL link uses PPPoA and handles 1500 byte IP packets.


Vernon Schryver    [email protected]

_______________________________________________
Pppext mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pppext