Fred,
About the Ethernet CRC, I would be happy if we left the IEEE standards
> alone to continue to
>
> do the CRC calculations as they have always done as long as there is a way
> to get the receiver
>
> to deliver packets that contain FEC errors to IP instead of dropping them
> unconditionally.
Fred,
MD5 is insecure, see RFC 9155 for the details.
Cheers,
Andy
On Mon, Nov 13, 2023 at 6:08 PM Templin (US), Fred L wrote:
> Herbie, what in your opinion would be the more preferable solution – use
> MD5 for which standards
>
> and implementations are widely deployed, or define new standar
Any hints on what this list is about?
Thanks,
Andy
-- Forwarded message -
From: IETF Secretariat
Date: Wed, May 25, 2022 at 11:37 AM
Subject: New Non-WG Mailing List: snac
To: IETF Announcement List
A new IETF non-working group email list has been created.
List address: s...@
;> I doubt that there is much L2TP still out there. It was in its prime
> with dialup modems. L2TPv3 which was intended to replace it became niche
> with, as Andy says, operators who did not want MPLS. Much of what L2TPv3
> was intended for was actually done with PW over MPLS with some replaceme
Bob,
In addition to the cases listed by Derek, L2TPv3 can also carry non-IP
pseudowire data, such as Ethernet frames (see RFC 4719 for example). Even
though 4719 says that sequencing is optional, I would certainly recommend
it :-).
But I guess that's really not what you were asking about, since y
Yiu,
Just FYI, this issue came up several years ago with regard to randomized
MAC addresses in Ethernet frames contained in Ethernet pseudowires. Stewart
and I wrote RFC 8469 to address the resulting effects that were encountered
in the field.
Cheers,
Andy
On Tue, Sep 22, 2020 at 3:50 PM Lee, Y
Bob,
I certainly agree, but I also wanted Behcet to at least have the most
up-to-date list.
Cheers,
Andy
On Fri, Sep 20, 2019 at 4:31 PM Bob Hinden wrote:
> Andy,
>
> > On Sep 20, 2019, at 10:37 AM, Andrew G. Malis wrote:
> >
> > Behcet,
> >
> > Tha
Behcet,
That was a historical list. The current assignments are in
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml .
If you want to go garbage collecting, that's the place to start.
Cheers,
Andy
On Fri, Sep 20, 2019 at 10:25 AM Behcet Sarikaya
wrote:
>
>
> On Thu, Sep
Erik,
IP Protocol numbers are a scarce resource and the allocation policy is
"IESG Approval or Standards Action". They aren't interested in the latter,
so they would need the former. So if they can legitimately reuse 114, it
makes everyone's life easier.
Cheers,
Andy
On Thu, Sep 19, 2019 at 5:2
Alex and Brian,
Any time you have a limited domain layer 2 network (such as a campus
Ethernet, or more application-specific networks like Alex was mentioning),
one thing that commonly occurs is that people want to use tunnels to
interconnect such networks either over the Internet, or alternatively
Jari,
Looks good. Your discussion of the use of the experimental values can
be replaced just by saying that use of the experimental values must
follow the guidelines in RFC 3692.
Cheers,
Andy
On Wed, Oct 22, 2008 at 5:33 AM, Jari Arkko <[EMAIL PROTECTED]> wrote:
> Since I was unable to find exis
ARP certainly precedes any notion of defining rules for how to add
code points. However, as a contributor to an RFC that extended ARP
(Inverse ARP, RFC 1293), at that time we wrote a draft in the IPLPDN
working group that defined the new code points, and it went through
the usual standards track pr
12 matches
Mail list logo
