Subject: RE: [Mip4] Re: RFC 3344 - Source Address of the RRQ & FHAE issues

From: "O'Neill Alan" <[email-masked]>
Date: Thu, 18 Mar 2004 19:35:40 -0500

Henrik / Sami,

Why don't we define the source address extension in RFC3344biz because FHAE
needs it in the discussed corner case, and state that it may be added into
the RREQ when the source address is not equal to the FA CoA, quoting the FHAE
example. You might also want to define a destination address extension as
well for completeness.

A short additional doc that can later wrap into NAT Trav can then build on
this and define the additional extensions for src and dest ports (and dest IP
if not included in RFC3344biz).

Alan.

-----Original Message-----
From: Henrik Levkowetz [mailto:[email-masked]] 
Sent: Friday, March 19, 2004 6:48 AM
To: [email-masked]
Cc: O'Neill Alan; [email-masked]
Subject: Re: [Mip4] Re: RFC 3344 - Source Address of the RRQ & FHAE issues

Hi Sami,

Thursday 18 March 2004, [email-masked] wrote:
> 
> > Hi Alan, 
> > 
> >     Your argument below is persuasive.  It seems to me this would be a
> > fairly clean solution which leaves 3344 as flexible as today, improves
> > NAT traversal and solves the deregistration FHAE problem.
> 
> I posted a reply earlier but it's probably still in moderation list.
> Anyway, I agree with Alan's comments as well. 

Yes.  A lot of mail hasn't made it to me at work today, so I'm picking
up a lot of stuff here at home.  Sorry for the delay ... :-)

> However, to me the most future proof solution is to add four fields
> into RFC 3519 or a new extension: src address, src port, dst address,
> dst post.  These should also go in both directions (MN/FA->HA, HA->MN/FA).
> As NATs operate on potentially all of these fields, it makes sense to
> provide the originals for MIP nodes (I know this may violate against
> UNSAF considerations more than RFC 3519 does, though.) 

Mm, yes, but we seem to be needing it.  I like it.

> The immediate use would be to cover the FA CoA issue under discussion,
> but having an "original src port" field would also cover the (admittedly
> corner) case where only the source port gets NATted.  This info could also
> be used to help with port forwarding (where destination address and/or port
> is translated; dest address only is not enough if only the port gets
> translated). 

Clearly not.

> Netseal implemented this as a separate extension which goes alongside
> the RFC 3519 extension.  But it could just as well be a part of the
> RFC 3519 extension(s).  Are there plans to revise RFC 3519 in the near
> future? 

No such plans at this time.  I don't know what's better - to write a short
draft defining new subtypes to the NAT traversal extensions 44 / 144, to
revise 3519, or to define a new extension for this in 3344bis...

I guess I'd think first in terms of a short separate document.

	Henrik

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 19 Mar 2004 05:54:20 +0100

Hi Alan,

> example. You might also want to define a destination address extension as

The main reason I was thinking to not do this in rfc3344bis is that the
purpose of the revision is to take it to Draft Standard, and we definitely
can forget about that with this addition.

> if not included in RFC3344biz).

Yes.  But don't you think the whole thing can be written up standalone as an
addition to NAT traversal - after all it's with NAT traversal it becomes 
interesting.  As long as you don't add any NAT traversal extension, 3344bis
is fine as is without this, no?

	Henrik

---

From: [email-masked]
Date: Fri, 19 Mar 2004 08:58:07 +0200

Alan & Henrik, 

> (Henrik)

Although I don't like proliferation of extensions, I'd have to agree.
In an ideal world I'd like to have RFC 3519 and this a part of the base
specification, though. 

> is fine as is without this, no?

As a practical matter it might be easiest to have this in an RFC 3519
revision (from an implementor's point of view).  Still, as the address
information may be useful in other situations too, a separate extension
may be warranted. 

I don't like the latter approach too much because it has overlapping
processing with RFC 3519 -- should an RFC 3519 compliant node do NAT
detection based on CoA field or these addresses, i.e. do we override
RFC 3519 semantics IF this extension is present?  If we don't, do we
require consistency checks, e.g. if MN is using co-located, CoA should
match original source address, etc. 

We implemented an extension ("original address info") containing the
four fields, and some of the rrq/rrp processing was complicated
slightly by that.  I've got some notes regarding the changes required
for rrq/rrp, so that might be helpful if we decide to use this route. 

Best, 

 -Sami