Subject: Re: (NAT) tcp options and non-routable names

From: Brian E Carpenter <[email-masked]>
Date: Sun, 21 Dec 1997 13:45:07 +0000

It would certainly be exceedingly anti-social to deploy a NAT
that silently discards SACK. In general the proposal to silently
discard non-understood TCP options is very worrying, since it will
lead to horrendous debugging problems if the option is actually
doing something necessary. 

  Brian Carpenter

>-- Philippe OECHSLIN wrote:
> 
> > >  I propose that we add a section saying that the nat should look out
> > >  for TCP option negociation in syn and syn-ack segments. If it sees
> > >  an option it doesn't know, it should silently remove it. If it sees
> > >  an option it can handle, it should register it in the translation
> > >  table and handle sequence numbers (or other fields) accordingly.
> >
> 
> > I think it is very unlikely to find an FTP implementation which use
> > some of the more exotic options of TCP or IP.
> 
> Well, TCP options and FTP are independent.
> 
> For example, most new protocol stacks now implement window scale option,
> although it is disabled by default. If you configure a host to use window
> scale option, then any application running on TCP will negociate that option
> without the application being aware of it.
> 
> Sack TCP is another option which will most likely be deployed in the next
> years.
> 
> There is a lot of concern in the IETF about things that NAT or NAPT can break.
> I think that TCP options is one of these. We should not wish it away but
> rather document the problem and its workaround in the NAT draft.
> 
>  Philippe
> 
> -
> > To unsubscribe, email [email-masked]' with
> > 'unsubscribe nat' in the body of the message.
> 
> -
> To unsubscribe, email [email-masked]' with
> 'unsubscribe nat' in the body of the message.

-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.