Identifier-Locator Network Protocol (ILNP) Architectural Description
draft-irtf-rrg-ilnp-arch-06

[Ballot comment]
 
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

[Ballot comment]
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.

[Ballot discuss]
I think that we need to go with at least the statement concerning LISP and HIP as these are experimental protocols being run by IETF WGs.

Additionally the document needs to include either a reference to to RFC 6115, or equivalent reservation text so that it is treated with parity WRT to the LISP documents. The document also needs to provide a reference to the LISP work.

The IPv4 text in the draft implies that we are continuing to develop IPv4 functionality and should be changed to make it clear that IPv4 is entering the end of its life.

[Ballot comment]
  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

[Ballot comment]
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.

[Ballot comment]
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.

this is a request for the IESG to perform an RFC5742 review of the following drafts describing ILNP from the RRG, to be published as RFCs on the IRTF Stream:

- draft-irtf-rrg-ilnp-adv-02 (Experimental)
- draft-irtf-rrg-ilnp-arch-02 (Experimental)
- draft-irtf-rrg-ilnp-arp-02 (Experimental)
- draft-irtf-rrg-ilnp-dns-02 (Experimental)
- draft-irtf-rrg-ilnp-eng-02 (Experimental)
- draft-irtf-rrg-ilnp-icmpv4-02 (Experimental)
- draft-irtf-rrg-ilnp-icmpv6-02 (Experimental)
- draft-irtf-rrg-ilnp-noncev6-02 (Experimental)
- draft-irtf-rrg-ilnp-v4opts-02 (Experimental)

These documents have been approved for publication by the IRSG. See http://wiki.tools.ietf.org/group/irtf/trac/ticket/42 for details on prior reviews. Please copy all correspondence to the document shepherd, Tony Li (tony.li@tony.li).

Also, please note that several of these documents require IESG Approval for codepoint registrations in various IANA registries. In the process of reviewing these documents under RFC5742 (i.e., for conflicts with IETF work), please also approve the necessary codepoints to enable experimentation with ILNP.

Thanks,
Lars