As Ron said, anyone can write a proposal. I have a hard time taking proposals seriously from someone who suggests interconnecting satellites with optical fiber, though.
Also, I can't imagine this actual proposal gaining any momentum, especially due to this note:
All Internet connected hosts must be IPv10 hosts to be able to
communicate regardless the ...
You must remember that anyone can submit proposals to the IETF, and they are taken seriously, until they are either adopted or die due to lack of interest.
This particular proposal has expired and been renewed by the author several times. It doesn't appear to have much, if any, support, and it doesn't even have a proposed RFC status, e.g. Standards Track. ...
A /31 network actually has two usable hosts for a point-to-point link. See the Standards Track RFC 3021, Using 31-Bit Prefixes on IPv4 Point-to-Point Links (published in December 2000):
With ever-increasing pressure to conserve IP address space on the
Internet, it makes sense to consider where relatively minor changes
can be made to ...
This part of the RFC is about passing responsibility over to the operating system or whatever is the next stage of the process. It's fundamentally concerned with the separation of layers.
An acknowledgment by TCP does not guarantee that the data has been delivered to the end user, but only that the receiving TCP has taken the responsibility to do so.
The IPv6 documentation prefix (2001:db8:::/32) must be used ONLY for documentation purposes. It means written examples, diagrams, PPT presentations, Textbook explanations, etc.
This range shouldn't be used in practical networks.
There is a "private IP range" of fc00::/7 which should be used for device testing, demos, courses, etc. as per RFC4193
Back when the RFC for private addressing was proposed, classful addressing was still common. The reasons for the three address ranges are found in RFC 1918, Address Allocation for Private Internets:
If a suitable subnetting scheme can be designed and is supported by
the equipment concerned, it is advisable to use the 24-bit block
(class A network) of ...
Is “IPv10” a joke or a serious RFC draft?
Both. I guess that bloke is serious and he doesn't get what ridiculous schemes he's proposing. The joke's on him.
The Fiber Satellite proposal is even more ludicrous as it neglects required fiber lengths (265,000 km per orbit in geosynchronous altitude) and totally ignores orbital mechanics (it's utterly impossible ...
The 100.64.0.0/10 address block is not private address space; it is shared address space. This is spelled out in RFC 6598, IANA-Reserved IPv4 Prefix for Shared Address Space (I highlighted the relevant verbiage):
IPv4 address space is nearly exhausted. However, ISPs must
continue to support IPv4 growth until IPv6 is fully deployed. ...
How Routers Handle Limited and Directed Broadcasts
The first thing to understand to answer your questions is that limited broadcast frames are not routed. By default when a router receives a frame with a destination address that is broadcast at either layer 2 or layer 3, the router simply drops the frame. That's why routers are said to be the boundary of ...
My question then is, what would the purpose be of sending an unordered list? In what cases would you be better off sending an unordered list as opposed to an ordered list?
as-set is commonly used when aggregating routes downstream of an autonomous system; so the use case for an unordered list is bgp aggregation.
In the example below, AS65500 ...
A Tale of Three Stubs...
When using Cisco equipment, OSPF calls several things a "stub"... it gets a bit confusing....
The meanings are very different for each term; even more confusing is the reality that you can potentially apply multiple stub terms to a single OSPF interface. I'll elaborate more below.
We have used /31s in our core (Brocade, Juniper, Cisco) for over three years with no issues whatsoever.
This is a production ISP network, and hence its appropriate to use them in a production environment as long as your kit supports it, and you've tested it
If your test environment is separated from your local network you hypothetically could use any IPv6 addresses which are not reserved for special uses. However, if you are looking for an equivalent of private IPv4 adresses you should take a look in RFC4193.
There you can see that fc00::/7 is the suitable subnet for testing purposes.
On the other hand you ...
The new ICMP message type as defined in this RFC actually was added to the ICMP standard - though it's currently listed as Historic in RFC 6918:
2.6. Traceroute (Type 30)
This message type is specified in [RFC1393] and was meant to provide
an alternative means to discover the path to a destination system.
This message type has never been widely ...
Every "header" has some sort of "Next Protocol" identification field. This is necessary because on the wire, the data is nothing but a string of 1's and 0's. The receiving endpoint must have a way of interpreting what the next bits refer to.
If not for such a field which definitively indicates how to interpret the next set of 1's and 0's, there would be ...
From the RFC perspective, the "end user" is the application. There's no guarantee that the application got the data, just that the TCP process received it.
From your NOC perspective, the network is functioning and data reached the end host. Presumably, that's all you care about.
Yes both LSR could advertise given FEC, say 10.0.0.1/32 with label 10 to each other.
Then if IGP says to LSR1 10.0.0.1/32 egress interface is towards LSR2, it'll impose (or swap to) label 10 and send towards LSR2. LSR2 then will find egress interface being something else than towards LSR1 and swap label to what ever that direction has advertised, might ...
In RFC 7084, it also states:
W-1: When the router is attached to the WAN interface link, it MUST
act as an IPv6 host for the purposes of stateless [RFC4862] or
stateful [RFC3315] interface address assignment.
So in short, yes - a router should be able to autoconfigure an IPv6 address for its WAN interface.
In reality though, most ...
TLA/NLA structure for IPv6 addresses
The TLA/NLA allocation structure has been deprecated in RFC 3587, August 2003:
2. TLA/NLA Made Historic
The TLA/NLA scheme has been replaced by a coordinated allocation policy
defined by the Regional Internet Registries (RIRs) [IPV6RIR].
Part of the motivation for obsoleting the TLA/NLA structure is
Opaque LSA's are used to extend the capabilities of OSPF, and to allow for transmission of arbitrary data that OSPF does not necessarily need to care about. For example, if you were writing an application and you decided you wanted to use OSPF to transport the application's data but you did not want OSPF to use this data for its own purposes, ie route ...
The destination UDP port in the outer UDP header is specified in the VXLAN specification (Port 4789). This means it is a well-known service. So an UDP packet that arrives on Port 4789 is expected to be a VXLAN packet¹ in the same way that a TCP packet that arrives on Port 80 is expected to be a HTTP packet¹.
The draft you linked to is outdated and is ...
RFC 5952 gives you the canonical IPv6 format. That is explained in the RFC itself:
This document defines a canonical textual representation format.
4. A Recommendation for IPv6 Text Representation
A recommendation for a canonical text representation format of IPv6
addresses is presented in this section.
There are people who incorrectly ...
That block of addresses is reserved for service providers to be able to do NAT in such a way that it doesn't conflict with the normal private address space. If you start using it as private space then you're potentially creating a conflict again, so no: don't use this as private space.
Officially RFC 6598 says
Devices MUST be capable of performing address translation when
identical Shared Address Space ranges are used on two different
Most NAT implementations are not capable of handing that case at least not witout extra hacks (on linux for example I belive that to implement NAT with overlapping internal and ...
Just from the RFC I can't see anything defining that documentation is
strictly written text. Do you have any source for this interpretation?
According to the IANA IPv6 Special-Purpose Address Registry, the 2001:db8::/32 Documentation address range cannot be used in source or destination addressing, is not forwardable (routable) nor globally reachable, and ...
Remember, the purpose of the algorithm is to avoid everyone picking FD00::/48 so they can abbreviate everything with the double colon. (Or other "easy" ones like FDAA:AAAA::/48, etc).
The section right above it (3.2.1) identifies that the formula in 3.2.2 is merely a suggested formula, not directed:
3.2.1. Locally Assigned Global IDs
Locally assigned ...
It appears to be a typo in that RFC. Notice that the header of the RFC says Errata Exist. It is not uncommon for things like that to happen.
That particular error is corrected in the errata. See the RFC Editor for the details.
Errata ID: 3485
Reported By: Markus Falb
Date Reported: 2013-02-18
Verifier Name: ...
It is merely a necessity constraint and personal preference.
If a Network is being built that would only have 10, or 20, or 50, or even 100 hosts, there is no reason not to use a /24 from 192.168.0.0/16. This is why home networks typically use the 192.168.0.0 range.
If a Network is being built that would (in all growth projections) only have up to 1000 or ...
The issue is that you're operating under the notion that each layer is in and of itself a separate, autonomous entity. Understand that IP is not the only packet delivery protocol in existence, it just happens to be the most common one. Also understand that these "layers" are simply abstraction tools - the take away is that each "layer" is dependent on the ...
Have you taken a look at the ipRouteTable OID in the RFC1213-MIB? (OID number 184.108.40.206.220.127.116.11)
I utilize this to pull the routing table out of several devices.
It is referenced by RFC 1213 which, on page 33, gives the following information:
-- The IP routing table contains an entry for each route
-- presently known to this entity.