Subject: [tsvwg] SCTP NAT support, draft-stewart-natsupp-tsvwg-00

From: "Dan Wing" <[email-masked]>
Date: Thu, 21 Jan 2010 18:02:18 -0800

Section 6: an SCTP client cannot determine if there is an SCTP-aware NAT 
between itself and the SCTP server.  That means an SCTP client always needs
to include the DISABLE_RESTART parameter.  I assume that has undesirable
side-effects, yes?  If so, perhaps a different design would be better,
such as having the SCTP server notice the port collision and send back an 
error, which causes the client to either (a) re-send an INIT with the 
DISABLE_RESTART parameter or (b) choose a different source port number 
and send a new INIT without the DISABLE_RESTART parameter.

Nit:  draft-stewart-natsupp-tsvwg updates RFC4960 and should say that
is the intent on the first page header ("Updates: 4960 (if approved)").

-d

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 22 Jan 2010 14:27:00 -0600

>is the intent on the first page header ("Updates: 4960 (if approved)").

I agree

James
(with my chair hat on)

---

From: "Stewart,Randall" <[email-masked]>
Date: Fri, 22 Jan 2010 13:17:48 -0800

James:

I am not sure I agree.. I can see both points. It is an extension to the
protocol, but if the endpoint agrees to do it, it changes the base protocol
specification. 

My feeling is since it is an option its not really updating the base spec.
The base spec does not change i.e. we would not put it into the base spec
like we did the checksum change if we respun another BIS. So my bottom line
inclination is that its NOT an update but an optional feature.. one that I
would hope everyone would implement but not part of the base spec.

R

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Friday, January 22, 2010 12:27 PM
To: Dan Wing; [email-masked]
Cc: [email-masked]
Subject: Re: [tsvwg] SCTP NAT support, draft-stewart-natsupp-tsvwg-00

I agree

James
(with my chair hat on)

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 22 Jan 2010 16:34:58 -0600

>protocol, but if the endpoint agrees to do it, it changes the base protocol

Doesn't this last point answer your question though?

This is something TSVWG needs to therefore be aware of, and, it is 
something implementers need to know when referencing or implementing 
SCTP as defined in RFC 4960 (that there is a modification that is 
specified to the base protocol that's possibl).

>would hope everyone would implement but not part of the base spec.

eeehhh.... hmmm.... implementers ought know know this exists, and 
that it optionally updates the base spec. Isn't this the same as if 
you put an (RFC 2119) OPTIONAL for this feature in 4960?  I'm 
thinking the results would be the same.

I could be wrong though.

James

---

From: Randy Stewart <[email-masked]>
Date: Sun, 24 Jan 2010 19:07:57 -0800

James:

My point is that it is optional behavior. Thus how can it "update" a  
base spec. I
guess we need to ask someone more aware of the finer points of what
updates RFCxxxx means.

If optional behavior can be said to update a base RFC then we need
the AUTH/ADD-IP and PR-SCTP specs to also say "updates RFC xxxx"

:-)

R

>> >is the intent on the first page header ("Updates: 4960 (if  

-----
Randall Stewart
[email-masked]

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 25 Jan 2010 13:25:50 -0600

>guess we need to ask someone more aware of the finer points of what

I was looking for a justification from the author(s) as to why this 
shouldn't be considered an update of 4960, as another WG chair 
suggested ... and this is what I get back (an abusive reply)?

I don't know who peed in your cornflakes this morning -- but don't 
take that out on anyone on this list, ok...

James

>>> >Section 6: an SCTP client cannot determine if there is an SCTP- aware NAT

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 25 Jan 2010 11:56:14 -0800

> From: Randy Stewart [mailto:[email-masked]] 
> Sent: Sunday, January 24, 2010 7:08 PM
> To: James M. Polk
> Cc: Dan Wing; [email-masked]; tsvwg
> base spec. I guess we need to ask someone more aware of the finer 
> points of what updates RFCxxxx means.

ICMP multi-part is an "Update" of ICMP, and is optional:
http://tools.ietf.org/html/rfc4884

TCP SACK is not an "Update" of TCP, and is optional:
http://tools.ietf.org/html/rfc2018

So, I don't see a simple rule for when Update is used.

Moving beyond my Nit comment, though:

In http://www.ietf.org/mail-archive/web/tsvwg/current/msg09765.html I wrote:

     Section 6: an SCTP client cannot determine if there is an
     SCTP-aware NAT between itself and the SCTP server.  That means an
     SCTP client always needs to include the DISABLE_RESTART
     parameter.  I assume that has undesirable side-effects, yes?  If
     so, perhaps a different design would be better, such as having
     the SCTP server notice the port collision and send back an error,
     which causes the client to either (a) re-send an INIT with the
     DISABLE_RESTART parameter or (b) choose a different source port
     number and send a new INIT without the DISABLE_RESTART parameter.

can we discuss that?

Reading http://tools.ietf.org/html/draft-stewart-natsupp-tsvwg-00#section-6, I
also don't understand what is supposed to happen if two SCTP clients behind an
SCTP-aware NAT choose the same SCTP source port, send DISABLE_RESTART in their
INIT, but the SCTP server doesn't support DISABLE_RESTART.  Is there a
discussion in the draft about what is supposed to occur in that situation?
The clients could detect the server doesn't support DISABLE_RESTART, but I
don't know what they're supposed to do with that knowledge.

-d

> >> protocol, but if the endpoint agrees to do it, it changes 
> the base  
> >> protocol
> >> specification.
> >
> >> inclination is that its NOT an update but an optional 
> feature.. one  
> >> that I
> >> >such as having the SCTP server notice the port collision 
> and send  
> >> back an
> >> >error, which causes the client to either (a) re-send an 
> INIT with  
> >> the

---

From: Randy Stewart <[email-masked]>
Date: Mon, 25 Jan 2010 13:40:02 -0800

> So, I don't see a simple rule for when Update is used.

So my confusion (i.e. not knowing what Updates means) [[no I did not
have cornflakes and no I am not angry.. just confused]].. seems to
be also reflected in the RFC series itself ;-)

So probably no one has the answer ;-)

>     number and send a new INIT without the DISABLE_RESTART parameter.

Yeah, I need to think about this.. it might be better to do some
negotiation here but.. then comes the question of how the server
tells... it would look like a restart to the server hmmmm...

> discussion in the draft about what is supposed to occur in that  

Nope, there sure is not .. we need to add that..

> don't know what they're supposed to do with that knowledge.

They would have to fail the connection and need to have a different  
port. Now
if the port was ephemeral (which most clients are) one could even do  
the rebinding
for the client in the kernel.... assuming that the client does not  
have other
connections up of course.

Michael (added now) any thoughts?

R

>>>> number

-----
Randall Stewart
[email-masked]

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 25 Jan 2010 23:39:40 +0100

> So probably no one has the answer ;-)
Why not continue, at least for the SCTP related specifications,
the principle we used up to now:
* if a feature / packet format is changed and this is *NOT*
  negotiated, then the documents updates RFC [24]960. This happened
  when the changed the checksum or moved to RFC 4960.
* if there is a negotiation at the beginning and no packet format
  of RFC 4960 is changed, then it is a protocol extension.

I need to put out an ID which will provide a way to register flags
bits for chunks. This ID would update 4960, since existing packet
formats and IANA procedures are changed.

Then the NAT document can refer to that and NOT update RFC 4960.
This is at least my understanding of some earlier discussion.
>>    parameter.  I assume that has undesirable side-effects, yes?  If
The side effect is that you can not restart...
> tells... it would look like a restart to the server hmmmm...
We do have a message which can be sent by a middlebox to notify
the client that it has to reselect a vtag. This is something
the server could also do, but it is important to note, that the
vtag is not visible at the API layer. So it can be done "just
in the SCTP layer".

Reselecting the port number is different. Port numbers are visible
by the application. The application might have called bind() to
select a particular port number of has requested the port number
via getsockname() or similar calls.
> Nope, there sure is not .. we need to add that..
Agreed.
> They would have to fail the connection and need to have a different port. Now
> if the port was ephemeral (which most clients are) one could even do the rebinding
> for the client in the kernel.... assuming that the client does not have other
I agree that we have to describe this. Let me think about this...

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 26 Jan 2010 09:19:09 +0100

> So probably no one has the answer ;-)

It has been varying in use. However, it is appropriate to use Updates if
it is something that the base spec implementor really should know of
even if it is optional functionality.

If it is like Dan writes and the result is that this option will be used
all or at least in most of the connection establishments then I think it
clearly is an update.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 26 Jan 2010 03:55:30 -0700

Magnus,

Has there been a consensus to make
draft-stewart-natsupp-tsvwg-00 a WG item?

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 26 Jan 2010 12:35:22 +0100

> draft-stewart-natsupp-tsvwg-00 a WG item?

Brian,

As an AD I have approved the WG taking this on as WG item. However, I
don't believe there has been a consensus call on taking this document as
the start. However, I am not aware of any alternative.

I see this is as necessary for TSVWG to take on to ensure that Behave
can deliver its WG item on SCTP NAT behavior.

Cheers

Magnus Westerlund

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 26 Jan 2010 06:21:53 -0700

Magnus,

I just thought that it would be good to comment on a WG item draft
before arguing whether it updates RFC 4960 or not.

On a related note: is RFC 4960 or SCTP ever going from PS to DS?

--brian

Magnus Westerlund wrote:                     (Tue, 26 Jan 2010 12:35:22)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 26 Jan 2010 14:50:26 +0100

> before arguing whether it updates RFC 4960 or not.

Well, with the expectation that the next update will be a WG item I
don't find it that strange. But I do agree that we should make it clear
that it is going to become a WG item.

> On a related note: is RFC 4960 or SCTP ever going from PS to DS?

A good question. There are I think primarily two questions. To what
extent is the Normative references of a status of DS or FS? (A certain
amount of exceptions can be handled)

Then there is the question of Implementation reports. All functionality
in SCTP needs to have been implemented in at least two different
code-bases and be tested against each other. This needs a written
report, please see RFC 5657 https://datatracker.ietf.org/doc/rfc5657/
for more info.

Cheers

Magnus Westerlund

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 26 Jan 2010 07:55:19 -0700

Magnus,

Magnus Westerlund wrote:                     (Tue, 26 Jan 2010 14:50:26)
> report, please see RFC 5657 https://datatracker.ietf.org/doc/rfc5657/

<rant>
Nowadays you use SCTP just about every time you make a phone
call.  SIGTRAN deployment (another set of PS RFCs) is poised to
overtake SS7 in deployment for heaven's sake.  Certainly the
requirements of RFC 2026 and RFC 5657 can be met by surveying
the widespread existing implementations and weeding out any
esoteric optional things (such as, perhaps, hostname in INIT).
Considering its widespread production deployment with SIGTRAN, I
find it amazing that it is not yet a full Internet Standard,
especially when compared to a lackadaisical work like SIP which
has long enjoyed full Internet Standard status.
</rant>

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 26 Jan 2010 16:15:32 +0100

> has long enjoyed full Internet Standard status.

SIP 2.0 (RFC 3261) is only a proposed standard.

As yourself indicate there are some work needed to bring SCTP to draft
standard. Nobody has yet done that work. If you care, why not go ahead
and do the work. With RFC 5657 the bar has been lowered compared to
before. We are also trying to make the downref issues be somewhat
possible to handle.

Cheers

Magnus Westerlund

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 27 Jan 2010 17:56:20 +0100

> report, please see RFC 5657 https://datatracker.ietf.org/doc/rfc5657/
Hi Magnus,

that is actually a very useful reference. Randy and myself have this
stuff on our todo list for a while, having a precise description really
helps! Thanks a lot.

Best regards
Michael

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 29 Jan 2010 15:47:35 +0800

Dear all,

Please allow me to comment.

I don't think this draft updates RFC4960,
In my understanding, if one draft updates another,  they should be in the same space.

If one draft is in one space, while another one is in a space of different level, I do not consider the update relation between 
them.
For example, RFC2460 is for IPv6, RFC3775 is for Mobile IPv6, does RFC3775 update RFC2460? I see no such relation in IETF.
And, RFC2460 is also not updated by all IPv6-related documents.

As to SCTP cases, RFC2960 was updated by RFC3309, they are in the same space (in fact RFC3309 is in a subspace of RFC2460).
But the SCTP-NAT-draft and RFC4960 are in different space.

Regards
Xiangsong

----- Original Message ----- 
From: "Magnus Westerlund" <[email-masked]>
To: "Randy Stewart" <[email-masked]>; "tsvwg" <[email-masked]>; "Michael Tuexen" <[email-masked]>; 
<[email-masked]>; "Dan Wing" <[email-masked]>; "James M. Polk" <[email-masked]>
Sent: Tuesday, January 26, 2010 9:50 PM
Subject: Re: [tsvwg] SCTP NAT support, draft-stewart-natsupp-tsvwg-00

> that it is going to become a WG item.

--snip--

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 29 Jan 2010 13:19:03 -0600

Xiangsong

Please define "space" as you use it, as I cannot parse it (i.e., I 
can come up with uses of "space", but none work consistently through 
your examples).

A couple of examples of what I know, RFC4960 obsoleted RFC2960.

- So, in your definition - how does that affect RFC 3775?

- Of course RFCs 3309 or 3775 could have formally updated RFC 2960 at 
the time of its publication., and either could have obsoleted the 
previous current base spec of SCTP.

I guess I don't get the logic you are suggesting, that both 3309, 
3375 and all other IPv6 RFCs are outside of the Transport Area, which 
includes the TSVWG. Are you specifically talking about which WG or 
Area these IDs and RFCs were generated in?

That is actually part of the question -- as Dan Wing (BEHAVE WG 
chair) is very conscious of anything in his WG updating any other 
WG's (or Area's) protocols.  HE and I have talked frequently and this 
topic as his WG is working on various ways that transport protocols 
can be modified to traverse NATs, and he prefers (which I agree with) 
any changes to the transport protocols be done in the protocol's home 
WG (TCP in TCPM WG, SCTP and UDP in TSVWG, and DCCP in the DCCP WG).

The applicable WG chairs and the Transport ADs are discussing how 
*not* to duplicate or replicate new (and different) ways for each 
transport protocol to traverse NATs. We're unofficially looking for a 
generic mechanism (i.e., in one ID) that covers all transport 
protocols can traverse NAT the same way.  This reduces complexity and 
therefore it's probably this approach will increase interoperability 
(especially for the HOMEGATE group).

James

At 01:47 AM 1/29/2010, Xiangsong Cui wrote:
>If one draft is in one space, while another one is in a space of 
>different level, I do not consider the update relation between them.
>For example, RFC2460 is for IPv6, RFC3775 is for Mobile IPv6, does 
>RFC3775 update RFC2460? I see no such relation in IETF.
>As to SCTP cases, RFC2960 was updated by RFC3309, they are in the 
>same space (in fact RFC3309 is in a subspace of RFC2460).
>----- Original Message ----- From: "Magnus Westerlund" 
><[email-masked]>
>To: "Randy Stewart" <[email-masked]>; "tsvwg" 
><[email-masked]>; "Michael Tuexen" <[email-masked]>; 
><[email-masked]>; "Dan Wing" 
><[email-masked]>; "James M. Polk" <[email-masked]>

---

From: Xiangsong Cui <[email-masked]>
Date: Sat, 30 Jan 2010 09:57:12 +0800

Dear James,

Firstly I want to explain RFC3775 issue, which is mentioned in my example.
RFC2460 and RFC3775 (and also other *IPv6-related documents* I said) are INT area documents, I did not want to relate them with TSV 
area. But, I suppose the criterion of UPDATE is applicable for IETF, I mean all areas and wgs. In my understanding, RFC2460 is the 
basic specification of IPv6, and RFC3775 is the specification of Mobile IPv6. In section 4.2 of RFC3775, the title is *New IPv6 
Protocol*, and the first sentence is *Mobile IPv6 defines a new IPv6 protocol, using the Mobility Header*. Does this mean RFC3775 
update RFC2460? I see no such statement, and I guess nobody think that relation.

Well, I come back to TSV area now. The definition of space is hard to me, I can not give the accurate statement. But as Alfred 
showed us the definition of UPDATES, I think the terminology is not omnipotent :(
I understand same space as the same goal, the same procedure, the same influenced scope, the same participating elements ... If one 
is a part of another, I would also take them as same space, the space here is the space of the bigger one.
By this criterion, I consider following relations:
1, A adds some content to B, and A does not modify the original content of B
2, A removes some content of B
3, A modifies some content of B, but introduces no new functionality, no new feature, no new requirement... I would like to call it 
as pure modify.
4, mixed change, both adding or removing, both adding and pure modify, etc.
I think case 1 is NOT UPDATE, because A is in new "space", cases 2 and 3 are UPDATE, because A is in the same "space" of B. Case 4 
is hard, I would like to take a supplementary rule, Can we use specification B without consideration of specification A?
I think the update relation means: when the developers read the updated specification, the updating specification MUST, or SHOULD, 
or strongly recommended by IETF, to be read at the same time. Is that right?
By this standard, I think SCTP-NAT-draft does not update RFC4960. Because I know many scenarios, where SCTP is adopted in the telco 
network infrastructures. There is no NAT device in these networks, why requiring the developers to reading the NAT draft as the 
updating specification?

Regards

Xiangsong

----- Original Message ----- 
From: "James M. Polk" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>; "Magnus Westerlund" <[email-masked]>; "Randy Stewart" 
<[email-masked]>; "tsvwg" <[email-masked]>; "Michael Tuexen" <[email-masked]>; 
<[email-masked]>; "Dan Wing" <[email-masked]>
Sent: Saturday, January 30, 2010 3:19 AM
Subject: Re: [tsvwg] SCTP NAT support, draft-stewart-natsupp-tsvwg-00

> Xiangsong
>
> Please define "space" as you use it, as I cannot parse it (i.e., I can come up with uses of "space", but none work consistently 
> through your examples).
>
> - Of course RFCs 3309 or 3775 could have formally updated RFC 2960 at the time of its publication., and either could have 
> obsoleted the previous current base spec of SCTP.
>
> I guess I don't get the logic you are suggesting, that both 3309, 3375 and all other IPv6 RFCs are outside of the Transport Area, 
> which includes the TSVWG. Are you specifically talking about which WG or Area these IDs and RFCs were generated in?
>
> That is actually part of the question -- as Dan Wing (BEHAVE WG chair) is very conscious of anything in his WG updating any other 
> WG's (or Area's) protocols.  HE and I have talked frequently and this topic as his WG is working on various ways that transport 
> protocols can be modified to traverse NATs, and he prefers (which I agree with) any changes to the transport protocols be done in 
> the protocol's home WG (TCP in TCPM WG, SCTP and UDP in TSVWG, and DCCP in the DCCP WG).
>
> The applicable WG chairs and the Transport ADs are discussing how *not* to duplicate or replicate new (and different) ways for 
> each transport protocol to traverse NATs. We're unofficially looking for a generic mechanism (i.e., in one ID) that covers all 
> transport protocols can traverse NAT the same way.  This reduces complexity and therefore it's probably this approach will 
> increase interoperability (especially for the HOMEGATE group).
>
> James
>
>>----- Original Message ----- From: "Magnus Westerlund" <[email-masked]>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 30 Jan 2010 13:32:24 -0700

Xiangsong,

I agree.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/