Subject: [lisp] [#5] LISP protocol version

From: Sam Hartman <[email-masked]>
Date: Wed, 12 Aug 2009 15:51:03 -0400

Discussion earlier on the list focused on whether there was a need for
an explicit lisp protocol version in the header.  Several participants
argued that LISP could change its port if a new version was needed.
This issue tracks that discussion.

Unless someone objects by August 20, I'll conclude that the consensus
of the WG is that no version is needed.

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 12 Aug 2009 16:32:53 -0400

In this discussion, I indicated that using a new port for a new  
version of LISP would work (technically), but that I didn't think it  
was the best choice.  In general, I think it is better for a protocol  
to provide for its own versioning, rather than using up resources  
associated with a lower-layer protocol.

Also, I have been thinking about this a bit more since then, and I  
wonder about the operational implications of using a new port for each  
new version of a higher-layer protocol...  This means that if a site  
administrator wants to block (or enable) LISP in his firewall, he  
would have to keep track of new LISP versions and block (or accept) a  
new UDP port for each new version of LISP.

So, while I'm not strongly religious on this topic, I think it would  
be better if LISP provided its own versioning field.

If we choose to go with the plan that we'll use a new UDP port if we  
ever need a new version of LISP, I'd like us to explicitly document  
that, so that it is clear that this was an intentional choice.

Margaret

On Aug 12, 2009, at 3:51 PM, Sam Hartman wrote:

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Aug 2009 16:41:05 -0400

I am actually inclined towards the port number, because I think if we 
actually need a new version it will be a new protocol.

But, having said that, I note that the IANA just sent in an I-D on port 
number allocation policy indicating that folks should be somewhat 
cautious about blithely consuming port numbers.

Yours,
Joel

Margaret Wasserman wrote:
> 
> In this discussion, I indicated that using a new port for a new version 
> of LISP would work (technically), but that I didn't think it was the 
> best choice.  In general, I think it is better for a protocol to provide 
> for its own versioning, rather than using up resources associated with a 
> lower-layer protocol.
> 
> administrator wants to block (or enable) LISP in his firewall, he would 
> have to keep track of new LISP versions and block (or accept) a new UDP 
> port for each new version of LISP.
> 
> So, while I'm not strongly religious on this topic, I think it would be 
> better if LISP provided its own versioning field.
>

---

From: Sam Hartman <[email-masked]>
Date: Wed, 12 Aug 2009 16:42:00 -0400

Thanks for refreshing my memory.  OK, so we need comments on how to
resolve this.

Personally, I definitely support the plan of documenting our
extensibility choice no matter what it is.

---

From: Lars Eggert <[email-masked]>
Date: Thu, 13 Aug 2009 11:10:17 +0300

Hi,

> argued that LISP could change its port if a new version was needed.

note that draft-ietf-tsvwg-iana-ports documents some of the informal  
rules that IANA as been using when deciding on port allocations.  
Section 5.1 says:

    A given service is expected to further demultiplex messages where
    possible.  For example, applications and protocols are expected to
    include in-band version information, so that future versions of the
    application or protocol can share the same allocated port.

The standing recommendation is to include a version field.

Lars

---

From: Sam Hartman <[email-masked]>
Date: Thu, 13 Aug 2009 08:17:54 -0400

>>>>> "Lars" == Lars Eggert <[email-masked]> writes:
    Lars>    A given service is expected to further demultiplex
    Lars> messages where possible.  For example, applications and
    Lars> protocols are expected to include in-band version
    Lars> information, so that future versions of the application or
    Lars> protocol can share the same allocated port.

Is this true even in cases where changes to the version are expected
to be incompatible and old receivers are not expected to work with new
senders?

---

From: Eliot Lear <[email-masked]>
Date: Mon, 17 Aug 2009 18:58:42 +0200

Joel,

As one of the IANA expert reviewers for port assignments, in general
we'll be pretty harsh with application-level protocols that apply for a
port without a version #.  In particular, we won't approve updates to
that protocol, for sure.

This case is different.  LISP is meant to sit under EVERYTHING, and the
protocol version number, even though only a byte is a byte EVERYWHERE
that could get even get wrapped around a few times.  As such, were the
review to fall to me, I would recommend approval without a version #.

Eliot

On 8/12/09 10:41 PM, Joel M. Halpern wrote:
> But, having said that, I note that the IANA just sent in an I-D on
> port number allocation policy indicating that folks should be somewhat
>> wonder about the operational implications of using a new port for
>> each new version of a higher-layer protocol...  This means that if a
>> site administrator wants to block (or enable) LISP in his firewall,
>> he would have to keep track of new LISP versions and block (or
>> accept) a new UDP port for each new version of LISP.
>>