Subject: [Tsvwg] Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13

From: Joe Touch <[email-masked]>
Date: Mon, 23 Apr 2007 11:38:10 -0700

Pyda Srisuresh wrote:
> --- Joe Touch <[email-masked]> wrote:
...
>>> So any discussion which is based on the semantics of a
>>> router/switch/host is IMO, useless, since things have evolved.
>> Until the requirements in the IETF are updated to reflect this opinion,
>> it is irrelevant.
>>
> [suresh] I agree with Ananth. Things have evolved considerably since the
> introduction of NATs, web and peer networking. Any discussion based on
> semantics and not on present day deployment is not going to be useful, IMHO.

If you're proposing to redefine 1812 to include what a NAT does, go
ahead, and good luck.

Until then, IETF WGs need to stay within the scope of IETF standards.
Public opinion doesn't update those standards until we do.

>>> Also, actually, when you say "NAT's are not routers", there is a lot of
>>> ambiguity there :
>>>
>>> Typical case where NAT is configured in a router, which means that this
>>> device, applies NAT rule and route's the packets. 
> [suresh] Exactly. That is how NATs route. NATs translate IP addresses before
> forwarding.
> 
>> Then the part that routes must obey RFC1812 rules. If the part that
>> routes can respond in lieu of the part that NATs, then that's fine. But
>> when the part that NATs acts, it can't act like the router.
>>
> [suresh] So, if the part that does "NAT function" tells the part that does
> "route fucntion" that the router cannot forward the packet 

That's nonsensical and 1812 does not apply. NAT functions are not
required on routers, and routers do not expect such signals from NAT
functions.

> (Cause: Resource
> constraint or admin restrictions), what error code shoud the part that does
> "route function" use when sending ICMP error message back to the sender? Are
> you saying this cannot be any of the error codes specified in RFC 1812?

When caused by a NAT issue, yes, I'm saying it's inappropriate to co-opt
router messages.

...
>> However, in the case of the combined device, it still makes sense to
>> determine WHY an error code is being generated. If because of a routing
>> issue, then RFC1812 works; if because of a NAT issue, then RFC1812 is
>> NOT the guiding document.
>>
> [suresh] Joe - This is really a semantics argument. We have had discussions in
> the BEHAVE WG on which error code to use and settled on error code 13 as the
> most appropriate. This requirement has been in the draft for 6 months now. 

And it's being reviewed by people outside the WG now, which is why it's
being discussed now.

> I will go with whatever the WG decides in the end. DO you think it is really
> necessary to invent a new ICMP error code for the error cause we are talking
> about? I think not. My 2c.

Yes, I do. And I think this is necessary for exactly every reason anyone
else does NOT want to generate a new error code. NATs are NOT routers.

Joe

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 23 Apr 2007 11:17:51 -0700 (PDT)

--- Joe Touch <[email-masked]> wrote:

> 
> 
> Anantha Ramaiah (ananth) wrote:
> > Firstly, why is this being disussed in tcpm? This doesn't apply to TCP
> > directly. [ even in-directly it might apply to all other transport
> > protocols who can/may want to act on these errors] Maybe tsvwg is more
> > appropriate? 
> 
> That's possible; someone in Behave might start by posting a summary of
> the question there as well.
> 
[suresh] Agree with Ananth's comment. This is likely more applicable to tsvwg
than tcpm. I am replacing tcpm with tsvwg.

> > As far as the current discussion goes, there is a thin line of
> > distinction between hosts and routers, today.
> 
> There may be many devices that do both functions, but to the extent they
> do they must then obey both the host and router requirements.
> 
> > Today's routers do all
> > sort of things which were only done by end-hosts at one point of time.
> 
> Such as? Other than acting like end hosts for connections that terminate
> at routers, which they have always done, and always required
> RFC1122-level support...
> 

"route fucntion" that the router cannot forward the packet (Cause: Resource

> > So are you saying :-
> ...
> > - generate a ICMP error code if the error is a result of a "routing
> > operation" and NOT as a result of "NAT operation"? 
> 
> Yes.
> 
> > I really don't see a
> > value in seperating these and it boils down to pure semantic argument,
> > IMO, without considering the characteristics of the deployed Internet
> > today. 
> 
[suresh] Right. Full agree with Ananth. Coulndt have said it better.

> First, there are plenty of devices that do not combine both functions,
> and that's where we're talking about.
> 

regards,
suresh

> Joe
> 
> >> -----Original Message-----
> >> From: Joe Touch [mailto:[email-masked]] 
> >> Sent: Sunday, April 22, 2007 2:12 PM
> >> To: Pyda Srisuresh
> >> Cc: [email-masked]; [email-masked]; Mahesh Govind (mgovind); 
> >> Dan Wing (dwing); Faisal Siyavudeen (fsiyavud)
> >> Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13
> >>
> >>
> >>
> >> Pyda Srisuresh wrote:
> >>> Below is what RFC 1812 has to say about what constitutes a router.
> >>>
> >>>   This memo defines and discusses requirements for devices 
> >> that perform
> >>>   the network layer forwarding function of the Internet 
> >> protocol suite.
> >>>   The Internet community usually refers to such devices as 
> >> IP routers or
> >>>   simply routers.
> >> The rest of that document is what defines what is an Internet router.
> >> Being a device that does network layer forwarding and 
> >> violates any of the rest of that doc means that device is not 
> >> an Internet router.
> >>
> >>> NATs forward IP packets from one network to another. That 
> >> makes NAT a router.
> >>
> >> NATs don't follow the requirement of:
> >> 	- decrement the TTL
> >> 	- do not modify the source or destination IP address
> >> 		(except as per source-routing options)
> >>
> >> ...
> >>> If you insist NAT is not a router, I am not going to argue 
> >> or get into 
> >>> a debate with you on this. I will simply disagree. So do the vast 
> >>> majority of people taht use NATs to connect to public networks.
> >> They can and have disagreed before, but this isn't up for a 
> >> popular vote. It's utterly useless to talk about using any 
> >> sort of IETF standard
> >> - including ICMP type 3 code 13 - and expect the rest of the 
> >> Internet to follow that standard when NATs violate the 
> >> standard of what it means to be a router.
> >>
> >> Joe
> >>
> >>
> > 
> > _______________________________________________
> > tcpm mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/tcpm
> 
> -- 
> ----------------------------------------
> Joe Touch
> Sr. Network Engineer, USAF TSAT Space Segment
> 
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 24 Apr 2007 06:21:23 -0700

> Joe,
...
> I read this as "NATs are not routers", which sounds like a possibly
> incorrect assertion.
> 
> I think NATs can (and perhaps must) also be routers (i.e. they can,
> and perhaps must, meet the requirements of an Internet router or
> Internet host despite their NATishness).

As per my other note, that is an interesting position, but adds a
requirement that is not already there.

Joe