Identifier-Locator Network Protocol (ILNP) Architectural Description
RFC 6740
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
(Adrian Farrel; former steering group member) Yes
The LISP documents (currently in the RFC Editor Queue for publication as Experimental RFCs in the IETF Stream) have clear and unambiguous text to caution the user about the unknown side-effects of conducting the experiment on the Internet. For example, draft-ietf-lisp-23 says: This experimental specification has areas that require additional experience and measurement. It is NOT RECOMMENDED for deployment beyond experimental situations. Results of experimentation may lead to modifications and enhancements of protocol mechanisms defined in this document. See Section 15 for specific, known issues that are in need of further work during development, implementation, and experimentation. An examination of the implications of LISP on Internet traffic, applications, routers, and security is for future study. This analysis will explain what role LISP can play in scalable routing and will also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on. It seems to me highly desirable that similar caveats be applied to this work and added to the front of all ILNP documents. I strongly urge the authors and IRSG to apply such text. This is particularly important in this document as it is the cornerstone of the ILNP project. I believe it would also be really good to do more analysis in this document of what type of further experimentation is welcomed, and how it should be carried out. Without that, this document is little more than a hostoric record. --- A reference in the Introduction to RFC 6115 would be highly appropriate.
(Ron Bonica; former steering group member) (was No Objection) Yes
(Barry Leiba; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
I am fine with either 5742 IESG note, but if we go with the latter one about LISP and HIP, it should probably apply to all of the documents. I don't know what Lars would do differently based on the IESG note, so it is probably moot.
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
(Stewart Bryant; former steering group member) (was Discuss) No Objection
SB> This document should provide the reader with greater context
by the inclusion of a reference to RFC6115.
SB> The authors are requested to review the document to make
that the reader is not given the impression that the IETF is
actively enhancing the functionality of IPv4.
be mapped and then tunnelled through the inter-domain core of the
Internet. Another class being considered is sometimes known as
"Identifier/Locator Split". This document relates to a proposal
that is in the latter class of evolutionary approaches.
SB> Given that LISP is an IETF WG which seems to be operating in
SB> this area, why is there no reference to this work?
when designing the TCP/IP protocol suite. Unfortunately, that
separation did not occur, so the deployed IPv4 and IPv6 Internet
entangles upper-layer protocols (e.g. TCP, UDP) with
network-layer routing and topology information (e.g. IP
addresses) [IEN1] [RFC768] [RFC793].
SB> You can have ID/Loc splitting below the transport layer and there are many ways to design it.
The key idea proposed for ILNP is to directly and specifically
change the overloaded semantics of the IP address. The Internet
community has indicated explicitly, several times, that this use
of overloaded semantics is a significant problem with the use of
the Internet protocol today [RFC1498] [RFC2101] [RFC2956]
[RFC4984].
SB> Please be aware that there are a number of competing proposal to encode information in an IPv6 address.
Layer | IP | ILNP
---------------+----------------------+---------------
Application | FQDN or IP address | FQDN
Transport | IP address | Identifier
Network | IP address | Locator
Physical i/f | IP address | MAC address
---------------+----------------------+---------------
SB> What if the physical interface is not a LAN?
SB> Surely IP resolves an IP address to a physical interface or indeed a virtual interface. This is particularly
SB> necessary with an unnumbered interface.
SB>
SB> You might consider borrowing the notation used by the Transport Network(sic) engineers and use a client
SB> server model when you go below IP.
SB>
SB> Hopefully you later consider recursive newtwork designs.
Where, today, IP packets have:
- source IP address, destination IP address
instead ILNP packets have:
- source I-LV, destination I-LV
However, it must be emphasised that the I-LV and the IP address
are *not* equivalent.
With these naming enhancements, we will improve the Internet
architecture by adding explicit harmonised support for many
functions, such as multi-homing, mobility and IP Security.
SB> This is a view of the network based on the concept of a
SB> classic global IP layer.
SB> There are many new applications emerging that don't think that
SB> way and want multiple instances. In other words they have
SB> addresses that exist outside the network - sort of Godel addresses.
Specifically in response to [RFC4984], ILNP improves routing
scalability by helping multi-homed sites operate effectively with
provider-aggregatable (PA) address prefixes. Many multi-homed
sites today request provider-independent (PI) address prefixes so
they can provide session survivability despite the failure of one
or more access links or Internet Service Providers (ISPs). ILNP
provides this session survivability by having a
provider-independent node Identifier value that is free of any
topological semantics. This I value can be bound dynamically to a
provider-aggregatable L value, the latter being a topological
SB> I may have missed it, but I do not see a definition or "I" or "L"
3. ARCHITECTURAL CHANGES INTRODUCED BY ILNP
3.1 Identifiers
In normal operation, a node will not change its set of valid
Identifier values frequently. However, a node MAY change its set
SB>You do not define frequently.
of valid Identifier values over time, for example in an effort to
provide identity obfuscation, while remaining subject to the
architectural rule of the preceding paragraph.
SB> Surely there are less arcane reasons to change identity besides
SB> security by obscurity, for example there are business reasons
SB> such as restructuring the business or re-purposing of the
SB> equipment.
3.1.2 Syntax
ILNP Identifiers have the same syntax as IPv6 Interface
Identifiers [RFC4291], based on the EUI-64 format [IEEE-EUI],
which helps with backwards compatibility.
SB> IFF the requirement is to solve the problem with a single
SB> layer of encapsulation.
There is no semantic
equivalent to an ILNP Identifier in IPv4 or IPv6 today.
SB> Is this true? You could regard the problem as solved
SB> by updating DNS, thus the issue is not semantics
SB> but performance in today's networks.
The Modified EUI-64 syntax used by both ILNP Identifiers and IPv6
Interface Identifiers contains a bit indicating whether the value
has global-scope or local-scope [IEEE-EUI] [RFC4219]. ILNP
Identifiers have either global-scope or local-scope. If they have
global scope, they SHOULD be globally unique.
SB> Why are global (and you need to define global) identifiers
SB> not REQUIRED to be unique?
Regardless of whether an Identifier is global-scope or
local-scope, an Identifier MUST be unique within the scope of a
given Locator value to which it is bound for a given session or
packet flow.
SB> For that network instance.
As an example, with ILNPv6, the ordinary IPv6
Neighbour Discovery (ND) processes ensure that this is true, just
as ND ensures that no two IPv6 nodes on the same IPv6 subnetwork
have the same IPv6 address at the same time.
SB> Is that true, or do mean that no more than two are concurrently
SB> operational in that network instance?
3.4 Notation
3.5 Transport-layer state and transport pseudo-headers
In ILNP, protocols above the network-layer do not use the Locator
values. Thus, the transport-layer uses only the I values for the
transport-layer state (e.g. TCP checksum, UDP checksum), as is
shown, for example, in expression (6) above.
SB> I have not seen you note to the reader that the code to calculate the
SB> transport checksums needs to change.
SB>
SB> Also surely NATs need to change as a result of this?
3.7 ILNP Multicasting
Multicast forwarding and routing are unchanged, in order to avoid
requiring changes in deployed IP routers and routing protocols.
ILNPv4 multicasting is the same as IETF standards-track IPv4
multicasting.
SB> What does this mean?
SB> You used the IPv4 address as a locator, so either ILNP does
SB> not support IPv4 m/c or you only support m/c to the loc.
5.1 Host Multi-Homing (H-MH)
At present, host multi-homing is not common in the deployed
Internet.
SB> Ah, what about all of the laptops that are connected
SB> to both Ethernet and WiFi? A number of these have
SB> one or more virtual network connections in addition.
8. BACKWARDS COMPATIBILITY & INCREMENTAL DEPLOYMENT
ILNPv4 is backwards compatible with existing IPv4. As the IPv4
address fields are used as 32-bit Locators, using only the
address prefix bits of the the 32-bit space, IPv4 routers also
would not require changes. An IPv4 router would be unaware
whether the packet being forwarded were classic IPv4 or the
proposed enhancement in ILNPv4 [ILNP-V4OPTS].
SB> Most IPv4 routers are aware that they are being presented
SB> with IPv4 packets carrying options
(Wesley Eddy; former steering group member) No Objection
I found one typo: Section 3.3: "thought it" -> "though it" In section 5.2, MP-TCP is actually being defined by the MPTCP working group (not TCPM). You could cite RFC 6182 for the MPTCP architecture.