[shara] draft-thaler-port-restricted-ip-issues: IP Model Issues

[<[e-mail]>]

Dear Dave, 

You wrote in your draft: "A "unicast address" is defined (e.g., in [RFC4291]) as an identifier
   for a single interface.  A packet sent to a unicast address is
   delivered to the interface identified by that address.  Many
   protocols, including ARP [RFC0826] [RFC5227] rely on this fact.

   Creating a port-restricted unicast IP address would require a change
   to the above definition so that it could be assigned to multiple
   interfaces (on different hosts) within the address's scope." 

Why it is needed to change the above definition to assign the same IP address to several interfaces? This is already the case with anycast addresses. 

Note that the shared IPv4 address is not used as an ** Identifier ** but as a ** Locator **. A secondary IPv4 address or an IPv6 address are required to be used as "Identifiers" or to rely on a L2 identifier to convey incoming traffic to the appropriate device among those sharing the same IPv4 address.

You wrote also "An anycast address is defined as an identifier
   for a set of interfaces, where a packet sent to an anycast address is
   delivered to the "nearest" interface according to the routing
   protocols' measure of distance.  For additional discussion of anycast
   considerations, see [I-D.iab-anycast-arch-implications]. An anycast
   address differs from a port-restricted IP address in that an anycast
   address may still be used with any protocol or port, and all
   interfaces with the same anycast address are considered equivalent."

IP shared address does not share the complications documented in I-D.iab-anycast-arch-implications since the delivery of packets destined to a shared IPv4 address is deterministic: relies on the destination IPv4 address and destination port. 


You wrote also "We must also consider the long-term impact of any change to the IP
   model.  We have learned by experience that there is a consistent
   demand for any IPv4 hacks to also show up in IPv6.  Typically the
   rationale is that once administrators and support personnel are used
   to something, they want to continue to use it, and specifically they
   want it to work the same way in IPv6.  For example, whereas it was
   originally expected that NAT would only ever be deployed for IPv4
   since IPv6 had plenty of address space.  However, recently there has
   been some vocal demand for NAT in IPv6 so that it can work the same
   way.  Hence the key learning is that simply declaring "this hack is
   only for IPv4" does not work."

Why this concern is specific to A+P? FYI, the majority of port-restricted solutions rely on IPv6, see for instance http://tools.ietf.org/html/draft-boucadair-behave-ipv6-portrange-04#section-6.7.

Cheers,
Med
 

 


*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************