Subject: RE: Again on port number for DS-MIPv6 (was: [Mip6] MN's address as seen by HA is not its CoA but NAT's address (when NAT))

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 27 Apr 2006 14:18:31 -0700

> Hesham, should I take the lack of reply as an 
 > acknowledgement that there
 > _is_ an issue about port numbers for NAT traversal?

=> No you should take it as indication of me being busy. 
The port numbers can be stored in the MIP6 implementation
after a BU is received and reused for normal traffic. You
can store them in the relevant BCE. So I don't see a problem here.

Hesham

 > 
 > Alex
 > 
 > Alexandru Petrescu wrote:
 > > Soliman, Hesham wrote:
 > >> Alex,
 > >> 
 > >> I don't understand the problem you seem to see with this. The 
 > >> packet is received with the src and dst ports in it, the 
 > receiving 
 > >> implementation would simply send outgoing packets to the src port 
 > >> in the received packet. What is the problem?
 > > 
 > > Hesham, the question is about implementing it.  At UDP 
 > level there's
 > >  no information available to "send outgoing packets to the src port
 > > in the received packet" simply because UDP doesn't know 
 > what packet 
 > > needs a response.  MIP6 does, and in in the case of BU/BAck only. 
 > > IPv6 doesn't. TCPv6 doess.  App carried in UDPv6 doess too.  But 
 > > these apps don't know about the below UDP naturally.
 > > 
 > > E.g. an IPv6 app on GW needing to write to MN behind NAT 
 > has no idea
 > >  about which UDP dst port number to use, and can't find it 
 > on GW.  Do
 > >  you agree?
 > > 
 > > The negative consequence is the following:  MN behind NAT 
 > sends BU in
 > >  UDP to GW, mip6 on GW gets it, GW _may_ know how to reply 
 > the BAck 
 > > UDP back to MN - and thus the "UDP tunnel" is open.  But 
 > after this,
 > >  if an UDPv6 app wants to write to MN it should write to 
 > some UDPv4 
 > > dst port number - which one?  If it uses the port number 
 > previously 
 > > used by BAck it's not necessarily the good one, because 
 > NAT may have
 > >  removed it.  Do you agree?
 > > 
 > > Alex
 > > 
 > > 
 > > 
 > >> In this context you can thing of IPv6 as an application running 
 > >> over UDP.
 > > 
 > > Assume
 > >> 
 > >> Hesham
 > >> 
 > >>> -----Original Message----- From: Alexandru Petrescu 
 > >>> [mailto:[email-masked]] Sent: Thursday, April 
 > >>> 27, 2006 1:39 PM To: Henrik Levkowetz Cc: Zhang, Qiang [NTK]; 
 > >>> [email-masked]; Soliman, Hesham Subject: Re: Again on port number 
 > >>> for DS-MIPv6 (was: [Mip6] MN's address as seen by HA is not its 
 > >>> CoA but NAT's address (when NAT))
 > >>> 
 > >>> Hi, let me bring back this issue about UDP port number with NAT,
 > >>>  in DS-MIPv6 draft-ietf-mip6-nemo-v4traversal-01.txt
 > >>> 
 > >>> The draft can't be implemented, because the Gateway/HA doesn't 
 > >>> know what to put in the dst port number of UDP packets sent back
 > >>>  to MN, through NAT.
 > >>> 
 > >>> Previously it was said that the Gateway would need to respond 
 > >>> back to the NAT with the right dst port number, but that would 
 > >>> not be a problem because UDP would copy the incoming src port 
 > >>> number and put it into the dst port number towards NAT.
 > >>> 
 > >>> Basically it's not enough to just say that "UDP responses go back
 > >>>  to the originating port" for several reasons.  For (1) strictly 
 > >>> speaking, there's no such thing as "UDP response".  The UDP 
 > >>> header only has src, dst ports and checksum, there is no id there
 > >>>  to be able to match responses.  Only a protocol carried by UDP,
 > >>>  such as DHCP or MIP has "responses", identified by "transaction
 > >>>  id" or "identification" respectively, present in the UDP
 > >>> payload. In DS-MIPv6 we try to carry IPv6 in UDP and IPv6 itself
 > >>> doesn't have a "IPv6 response" either, still because no special 
 > >>> identifier in the IPv6 packet.
 > >>> 
 > >>> Henrik Levkowetz wrote:
 > >>>> [...] regarding the Port number, Alex, but this is no
 > >>> different from
 > >>>> any other UDP responses, which go back to the originating port.
 > >>>> 
 > >>>> 
 > >>>> 
 > >>> 
 > >>> To re-iterate, it's not "UDP responses" that go back to 
 > >>> originating port but "[protocols carried by UDP] responses".  Our
 > >>>  carried protocol here is IPv6, and there's no "IPv6 response".
 > >>> 
 > >>> (2) The UDP encapsulating interfaces (I'm aware of) don't usually
 > >>>  respond to UDP packets.  What they do is encapsulate (or 
 > >>> de-capsulate) and forward to another interface, according to the 
 > >>> routing table.  The UDP code (not interface) just forwards the 
 > >>> datagram to the proper socket number, based only on port number.
 > >>> 
 > >>> To exemplify the problem: DS-MIPv6 section 4.1 "NAT detection and
 > >>>  traversal" suggests that the BAck is sent to MN in response of a
 > >>>  BU.  It is the mip6 code (modified to do DS-MIPv6) that will 
 > >>> send the BAck, and put it on the UDP interface.  It is not the 
 > >>> UDP code in the kernel that replies to this message, it's the 
 > >>> mip6 code.
 > >>> 
 > >>> (3) Even if the kernel UDP code sent a reply back, it does not 
 > >>> have means to store the src port of an incoming BU encapsulated 
 > >>> in UDP and eventually put same dst port in the UDP packet 
 > >>> encapsulating the reply. While TCP does save data with respect to
 > >>>  incoming packets and send back data accordingly, simple UDP 
 > >>> doesn't.
 > >>> 
 > >>> And this is not all.  If we simply add text in the document 
 > >>> saying that the dst port number of UDP packets sent to NAT MUST 
 > >>> be the same as the src port number in the UDP packet received 
 > >>> from NAT - it's not enough, because the spec should provide the 
 > >>> implementer a means to relate the two packets.  What could this 
 > >>> identifier be? And such that it can't be spoofed?  (the IPv4 src
 > >>>  address can't be used because there's only one NAT for many 
 > >>> mobiles behind it, the UDP src port is changed by NAT for same 
 > >>> ongoing flow).
 > >>> 
 > >>> How should we deal with the port numbers in UDP packets carrying 
 > >>> IPv6 when NAT?
 > >>> 
 > >>> Alex
 > >>> 
 > > 
 > > 
 > > _______________________________________________ Mip6 mailing list 
 > > [email-masked] https://www1.ietf.org/mailman/listinfo/mip6
 > 
 > 

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 27 Apr 2006 23:48:18 +0200

Soliman, Hesham wrote:
>> Hesham, should I take the lack of reply as an acknowledgement that 
>> there _is_ an issue about port numbers for NAT traversal?
> 

Sorry, I didn't mean to push.  Take your time.  It's common when some
people have time others don't :-)

> The port numbers can be stored in the MIP6 implementation after a BU
>  is received and reused for normal traffic. You can store them in the
>  relevant BCE.

I thought along the same lines.

Except that (1) the NAT src port number is visible in clear in UDP and
thus spoofable.  I guess it should not only present but protected too.

And (2) the port number may change while BU/BAck is not happening, and
depending on its periodicity it may be bad for apps.  I.e. if the
BU/BAck happens every 5 minutes then the worse an application can expect
is a break for 5 minutes.

Last meeting there was discussion on the mike about what to use
for heartbeat keepalive.  Echo request/Reply and figures like 100seconds
were mentioned.  That is still a lot for a streaming app, not to mention
VoIP.

Ping could be sent from MN to GW.  But at the same time there are IPv6
RAs sent on the UDP "tunnel" interface.  So Echo Reply might not be
needed actually, because the RAs represent the keepalive from GW to MN.
So maybe there should be something else than Echo Request for heartbeat.

Anyways, take your time.

Alex

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sat, 29 Apr 2006 00:59:34 +0900

Hi Alex

Your implementation is on the assumption that the MIP6 is implemented  
in the kernel.
Why may port number change??
I also don't know why RA is tunneled between MN and GW...

ryuji

On 2006/04/28, at 6:48, Alexandru Petrescu wrote:

> Soliman, Hesham wrote:
>>> Hesham, should I take the lack of reply as an acknowledgement  
>>> that there _is_ an issue about port numbers for NAT traversal?

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Apr 2006 18:38:08 +0200

> Your implementation is on the assumption that the MIP6 is implemented

Yes but that doesn't matter.  Being in the kernel does not exclude the
fact that it's the mip6 code that responds to BU, not UDP code.  Also,
think that any IPv6 application on GW may try to contact the MN while MN
is behind a NAT.  How does the ds-mipv6 code (either kernel or
userspace) know to encapsulate to what UDP port number?

> Why may port number change??

Because it does so.  Certain NATs deployed widely for a large number of
wireless subscribers do so.

Whenever MN opens a UDP "connection" through NAT to GW the state created
there only lasts for some time, for a timelength which is little
predictable.  And, since the draft doesn't offer a NAT state maintenance
procedure I assume the port number changes.  Is this wrong?

> I also don't know why RA is tunneled between MN and GW...

For MN to be able to simply auto-configure a IPv6 CoA when behind NAT.
How do you propose MN to auto-configure an IPv6 CoA when behind NAT?

Alex

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 28 Apr 2006 19:14:17 +0200

Hi Alexandru,

on 2006-04-28 18:38 Alexandru Petrescu said the following:
...

> procedure I assume the port number changes.  Is this wrong?

Yes, that is wrong.

The draft specifies a NAT state keepalive mechanism.  If that
wasn't the case, things wouldn't work.  In that you're quite right.

But with the keepalive mechanism, this does work, in the same manner
as the tested and verified mechanism of RFC 3519.

	Henrik

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Apr 2006 19:42:45 +0200

Henrik Levkowetz wrote:
> Hi Alexandru,
> 
> on 2006-04-28 18:38 Alexandru Petrescu said the following: ...
> 
>> Whenever MN opens a UDP "connection" through NAT to GW the state 
>> created there only lasts for some time, for a timelength which is 
>> little predictable.  And, since the draft doesn't offer a NAT state
>>  maintenance procedure I assume the port number changes.  Is this 
>> wrong?
> 
> Yes, that is wrong.

Partially.

> The draft specifies a NAT state keepalive mechanism.

The NAT state keepalive mechanism specified by draft is basically the
following:

> However, if the mobile node is not active, it will need to 
> periodically send a message to the home agent in order to refresh the
>  NAT binding. This can be done using the binding update message.

For one, when this BU/BAck happens and the NAT UDP src port number has
changed, the BAck will indeed go back.  But if after this BU/BAck
happening, GW/HA wants to send a BRR (to refresh the binding and the NAT
state)?  How does the code sending BRR know which was the port number
used by the code who sent BAck?  BRR is triggered by a timer while BAck
by reception of a BU.  It's not same code flow.

Second, if we need MN to simply auto-configure an IPv6 CoA while behind
NAT then there should be RAs over the UDP "tunnel".  If there are such
RAs, then the RA itself could contribute to maintain NAT state, so it
will be redundant with the BAck message.  Also here, if we want MN to
quickly handover between behind NAT and something else then these RAs
should happen quickly (every 1s or so).  If we wait for the BU/BAck to
happen in order for the NAT to open (every 10s at best) then handover is
slowed.

Third, BU/BAck is mainly meant to update HoA-CoA bindings.  Or, neither
changes while MN is behind NAT, even if MN changes its v4 address due to
v4 mobility.

Do you think this is enough to motivate a different mechanism for NAT
state maintenance than just BU/BAck?  Do you disagree with any of the
above items? (store NAT src port number on GW, BAck not needed for
keepalive, RA should happen on "tunnel", BU/BAck is not the right tool
for maintenance)?

> But with the keepalive mechanism, this does work,

The keepalive mechanism mentioned in the draft (BU/BAck) has not been
tested here.

> in the same manner as the tested and verified mechanism of RFC 3519.

That document talks about MIP4.  It does make sense to take advantage of
RegReq/RegRep to maintain NAT state, because the IPv4 address does
change every now and then.  But with DS-MIPv6 the IPv6 CoA doesn't
change at all while behind NAT.  Would you agree?

Also I'm wondering whether in that document the NAT src port number is
stored in the registration table so that other code than RegReq/RegRep
can take advantage of it?

Alex

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 28 Apr 2006 20:45:27 +0200

Hi Alexandru,

>>>  maintenance procedure I assume the port number changes.  Is this 

Completely.

> changed,

The whole point of the keepalive is to make sure that the port number
doesn't change, and *it will not change* if you use the keepalive
appropriately.

> the BAck will indeed go back.  But if after this BU/BAck

Nonsense.  All UDP applications basically work the same way: send the
response back to the originators source port.  I've implemented this
for MIPv4 NAT traversal.  Can you say the same?  Unless you've actually
coded this I'd suggest that you're whistling in the dark here.

> NAT then there should be RAs over the UDP "tunnel".

This has absolutely nothing to do with keepalives or NATs.  The only
guess at a relevant answer I have is that it seems like you haven't
read the draft at all.  Please do so.

<snip section related to IPv6 CoA in IPv4 network>

> changes while MN is behind NAT, even if MN changes its v4 address due to

Please read the draft.  If you can say that there's no BU needed if
the IPv4 CoA changes, I can't see how you can have read the draft.

> keepalive, RA should happen on "tunnel", BU/BAck is not the right tool

I think you need to read the draft.

> The keepalive mechanism mentioned in the draft (BU/BAck) has not been

??  I'm sorry that you haven't tested it.  Maybe you should.

> change at all while behind NAT.  Would you agree?

I think you've mixed this up wonderfully, and would prefer that you
read the draft before we discuss this any further.

> can take advantage of it?

Well, maybe the best way to find out is to read the document?

	Henrik

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Apr 2006 21:40:14 +0200

Henrik Levkowetz wrote:
>>>> Whenever MN opens a UDP "connection" through NAT to GW the 
>>>> state created there only lasts for some time, for a timelength
>>>>  which is little predictable.  And, since the draft doesn't 
>>>> offer a NAT state maintenance procedure I assume the port 
>>>> number changes.  Is this wrong?
>>> Yes, that is wrong.
>> Partially.
> 
> Completely.

28.5% false.

>> The NAT state keepalive mechanism specified by draft is basically 
>> the following:
>> 
>>> periodically send a message to the home agent in order to refresh
>>>  the NAT binding. This can be done using the binding update 
>>> message.
>> For one, when this BU/BAck happens and the NAT UDP src port number
>>  has changed,
> 

Indeed, _if_ used appropriately.  The way specified doesn't qualify as such.

>> the BAck will indeed go back.  But if after this BU/BAck happening,
>>  GW/HA wants to send a BRR (to refresh the binding and the NAT 
>> state)?  How does the code sending BRR know which was the port 
>> number used by the code who sent BAck?  BRR is triggered by a timer
>>  while BAck by reception of a BU.  It's not same code flow.
> 
>  response back to the originators source port.

We have no UDP "application" here.  The "application" is a MIP6
implementation which is not a payload type.  There's no service number
assigned to MIP6.  Real UDP applications are not preceded by IPv6
headers, they are carried by UDP headers.

> I've implemented this for MIPv4 NAT traversal.

Great.  On what deployed NATs have you tried it?

> Can you say the same?

I've implemented NAT traversal using the MIP4 NAT traversal, and for
MIP6.  The keepalive is every second RA and ping from both directions.
There is UDP virtual interface and there are IPv6 RAs on that.  The CoA
is IPv6, the HoA is IPv6 too.  No v4-mapped addresses.

For a long time (really!) I've tried to understand the logic by which
NAT changes its src addres and concluded that I can't conclude anything,
just that it changes it whenever it pleases.  Most certainly I've
concluded that NAT keepalives every 110s will risk (at most) 110s app
interrupts.

I've also successfully tested 6to4 on MN behind some more gentle NATs.

Can you say the same?

> Unless you've actually coded this I'd suggest that you're whistling 
> in the dark here.

Let me return this back, if you permit: unless you've actually tried it
against some deployed NATs etc etc...

>> Second, if we need MN to simply auto-configure an IPv6 CoA while 
>> behind NAT then there should be RAs over the UDP "tunnel".
> 

I did, several times, since earliest versions, discussed extensively on
the list.  If the draft doesn't specify that the address MN obtains
while behind NAT is a IPv6 Care-of Address from the tunnel interface
then that's its problem, not mine.

>> Third, BU/BAck is mainly meant to update HoA-CoA bindings.  Or, 
>> neither changes while MN is behind NAT, even if MN changes its v4 
>> address due to v4 mobility.
> 

The fact that the draft mentions nothing at all about MN having a real
IPv6 CoA when behind NAT is none of my faults.

The fact that DS-MIPv6 requires MN to support IPv4 Home Addresses, but
does not permit MN to have a real IPv6 CoA when behind NAT is
none of my faults either.

>> Do you think this is enough to motivate a different mechanism for 
>> NAT state maintenance than just BU/BAck?  Do you disagree with any
>>  of the above items? (store NAT src port number on GW, BAck not 
>> needed for keepalive, RA should happen on "tunnel", BU/BAck is not
>>  the right tool for maintenance)?
> 

Ok I'll try again.

>> The keepalive mechanism mentioned in the draft (BU/BAck) has not 
>> been tested here.
> 

I used ping and RAs, with parametrable timeouts, from both directions.
Isn't that the same with NAT traversal?  It's just traffic.  I haven't
used BU/BAck because the IPv6 address wouldn't change.

>> That document talks about MIP4.  It does make sense to take 
>> advantage of RegReq/RegRep to maintain NAT state, because the IPv4
>>  address does change every now and then.  But with DS-MIPv6 the
>> IPv6 CoA doesn't change at all while behind NAT.  Would you agree?
> 

Wonderful is our misunderstanding, indeed.

So there seems to be a common understanding that with DS-MIPv6 MN will
have no real IPv6 CoA when behind NAT...  well I, oppose that.

>> Also I'm wondering whether in that document the NAT src port number
>>  is stored in the registration table so that other code than 
>> RegReq/RegRep can take advantage of it?
> 

Will try again.  Maybe I should start with the requirements:

draft:
> Since running Mobile IPv4 and Mobile IPv6 simultaneously is 
> problematic (as illustrated in [MIP-PB]), this scenario adds a 
> requirement on Mobile IPv6 to support IPv4 home addresses.

Ok, but can MIPv6 MN (3775, 3776) still support an IPv6 Care-of Address
  for this Mobile Node when MN behind NAT, over the UDP "tunnel" interface?

How does 3776 work when the IPv6 CoA is actually an IPv4 CoA, and behind
NAT?  Because when behind NAT the IPv4 address for two MNs is the same.

How does HA know to whom to send traffic it intercepts for MN's HoA when
the CoA is NAT's public address and there's no port number saved?

And existing IPv6 bootstrapping work when CoA is IPv4 and not IPv6?

Or is this something new to work upon?

And finally, what do you guys have against MN having a real IPv6 CoA
when behind NAT?  What would that break?  Wouldn't software reusability
be good?  3775, 3776 and bootstrapping work work unmodified.

Alex

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 29 Apr 2006 00:48:36 +0200

>>>>> number changes.  Is this wrong?

Impressive figure.  I see you've backed it up with documented
calculations, too.

> Indeed, _if_ used appropriately.  The way specified doesn't qualify as such.

I believe you're wrong here.  Since 3519 is known to work, and this
draft describes an equivalent mechanism, you'll have to be very specific
about what doesn't work.  You haven't come close to this yet.

> headers, they are carried by UDP headers.

As is the IPv6 payload in this case.  *DID YOU READ THE DRAFT??????*

> Great.  On what deployed NATs have you tried it?

Oh, I'd guess around n*100 different ones.  Do you usually get the
brand and model of a firewall when you visit a hot-spot?

> is IPv6, the HoA is IPv6 too.  No v4-mapped addresses.

This sounds like an implementation which isn't 3519-compliant at all.

> concluded that NAT keepalives every 110s will risk (at most) 110s app

No wonder if you haven't implemented what's described - and it really
doesn't sound like it.

> I've also successfully tested 6to4 on MN behind some more gentle NATs.

Yup.

> then that's its problem, not mine.

You don't use an IPv6 CoA when you're in an IPv4 access, whether
behind a NAT or not.

> IPv6 CoA when behind NAT is none of my faults.

It doesn't.  It seems you haven't understood the basics.

> none of my faults either.

No, but understanding the basics of the mechanism is, I believe,
your responsibiltiy.

>> I think you need to read the draft.

Thank you.

>   for this Mobile Node when MN behind NAT, over the UDP "tunnel" interface?

Oh, I'm sure we could arrange for that, but there is no reason to, I
believe.

> NAT?  Because when behind NAT the IPv4 address for two MNs is the same.

That's why you need the UDP tunnel, using the port numbers to dis-
ambiguate the connections.

> the CoA is NAT's public address and there's no port number saved?

The statement that there's no port number used is incorrect.

> Or is this something new to work upon?

Probably

> be good?  3775, 3776 and bootstrapping work work unmodified.

If you want that functionality, define an extension for it.  I don't
see any reason to fake an IPv6 CoA when the active CoA is IPv4.

	Henrik

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 29 Apr 2006 01:23:59 +0200

Henrik Levkowetz wrote:

> draft describes an equivalent mechanism, you'll have to be very 
> specific about what doesn't work.  You haven't come close to this 
> yet.

Do you think a DS-MIPv6 section about "Assumptions on NAT for NAT
Traversal for DS-MIPv6" would be appropriate?  Know that I'm not trying
to have my name in the draft.  Anybody can write it.  Should at least
contain "This draft assumes that the NAT leaves open the DS-MIPv6 port
number [TBD]".

>>>> happening, GW/HA wants to send a BRR (to refresh the binding 
>>>> and the NAT state)?  How does the code sending BRR know which 
>>>> was the port number used by the code who sent BAck?  BRR is 
>>>> triggered by a timer while BAck by reception of a BU.  It's not
>>>>  same code flow.
>>> Nonsense.  All UDP applications basically work the same way: send
>>>  the response back to the originators source port.
>> implementation which is not a payload type.  There's no service 
>> number assigned to MIP6.  Real UDP applications are not preceded by
>>  IPv6 headers, they are carried by UDP headers.
> 

YEs, I meant IPv6 per se doesn't know to "reply back" to some request,
as DHCPv4 carried in UDPv4, or MIP4 carried in MIPv4 know.  Not
trolling, just read what I'm saying.

The protocol carried by IPv6 may know to reply back, but the UDPv4
carrying that IPv6 doesn't know.  Cross-layer architectural discussions 
can happen here, but it's not my intent.

> brand and model of a firewall when you visit a hot-spot?

No I don't get brand model.  I do get though the NAT's public address
and the open port numbers through it.  I can assure you that each ISP
lets out different things.  And I can assure you that it's not because
IANA says that there should be some port number open that it will.

>>> Can you say the same?
>> I've implemented NAT traversal using the MIP4 NAT traversal, and 
>> for MIP6.  The keepalive is every second RA and ping from both 
>> directions. There is UDP virtual interface and there are IPv6 RAs 
>> on that.  The CoA is IPv6, the HoA is IPv6 too.  No v4-mapped 
>> addresses.
> 

Sorry, I did my best.  That RFC is an excellent idea.  Especially it can
be re-used between MIP4 and MIP6.  I haven't participated into writing
it and still I got the idea from it and implemented it.  If the effort
of an implementor to write somebody else's doc is recognized with "not
correctly done" then I'm sorry.

>> I've also successfully tested 6to4 on MN behind some more gentle 

And so you know that having an IPv6 address on MN behind the NAT is not
"trolling".

>> I did, several times, since earliest versions, discussed 
>> extensively on the list.  If the draft doesn't specify that the 
>> address MN obtains while behind NAT is a IPv6 Care-of Address from
>>  the tunnel interface then that's its problem, not mine.
> 

Sorry, I don't get it.  It's just an IPv6 CoA on some tunnel interface.
  It's assigned on the MN.  IPv6 apps run over it.  You don't want me to
call it a CoA - fine!  But I use it.

>> The fact that the draft mentions nothing at all about MN having a 
>> real IPv6 CoA when behind NAT is none of my faults.
> 

Great great, and when I'll implement these basics you'll say it's
wrongly implemented.

>> The fact that DS-MIPv6 requires MN to support IPv4 Home Addresses,
>>  but does not permit MN to have a real IPv6 CoA when behind NAT is
> No, but understanding the basics of the mechanism is, I believe, your
>  responsibiltiy.

Henrik, the WG can't impose some users what the WG thinks the user
needs.  If an IPv6 user on some IPv6 MN is behind a NAT needs an IPv6
address to run his/her IPv6 application, the WG can't tell him/her "no
no, use an v4-mapped CoA, it's better".

>> Ok, but can MIPv6 MN (3775, 3776) still support an IPv6 Care-of 
>> Address for this Mobile Node when MN behind NAT, over the UDP 
>> "tunnel" interface?
> 

Why not?  Having a real IPv6 address on the MN is a godsend for pure
IPv6 applications and pure IPv6 DNS.  I won't ask you why you think
there's no reason because I don't want to troll.

>> How does HA know to whom to send traffic it intercepts for MN's HoA
>>  when the CoA is NAT's public address and there's no port number 
>> saved?
> 

Currently the port numbers aren't in the binding cache.

>> Or is this something new to work upon?

Why so if we can get that straight from the start?  Current
bootstrapping would work unmodified if the MN gets an IPv6 address when
behind NAT.

>> And finally, what do you guys have against MN having a real IPv6 
>> CoA when behind NAT?  What would that break?  Wouldn't software 
>> reusability be good?  3775, 3776 and bootstrapping work work 
>> unmodified.
> 

It's not a "fake IPv6" CoA.  It's a real IPv6 address.  It's publicly
routable on the entire IPv6 Internet.  It's distributed to it from the
real IPv6 prefix advertised to it by the HA (that I currently call GW).

I don't understand what you mean by fake.

Anyways.

Again, not trolling.  Otherwise a bit tired about this discussion.  I
guess others too.  Just take my intention to reuse the UDP tunnel of
MIP4 as a good intent, whatever that may mean for you, good or badly
implemented.

Alex

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 29 Apr 2006 11:21:56 +0200

Hi,

> contain "This draft assumes that the NAT leaves open the DS-MIPv6 port

No.  That's not even a NAT functionality you're talking about, it's
a firewall functionality.

> trolling, just read what I'm saying.

So there's a UDP encapsulation which is handled by the MIPv6 client
and the MIPv6 HA.  The IPv6 stack only sees the packet after this
has been removed, so shouldn't care and doesn't have to know.

> correctly done" then I'm sorry.

???  "The keepalive is every second RA and ping from both directions"
is very far from what's described in 3519.

> And so you know that having an IPv6 address on MN behind the NAT is not

No, but it has nothing to do with the current MIPv6 over IPv4 mechanism.

> call it a CoA - fine!  But I use it.

Terminology is important.  It's what makes a sane discussion possible.
A MIP CoA is a very specific thing, and if you use it about something
else, no wonder people get confused.

> Great great, and when I'll implement these basics you'll say it's

When you say things that doesn't match my understanding and what's in
the draft, what do you expect me to do??   Just say 'Yes, master' and
let you go on believing something which to me seems incorrect?  I say
that it seems you haven't understood the basics because that's the
way it seems to me, from what you're saying, *not* to insult you.

When the MN acquires an IPv4 address in an IPv4-only network and uses
that as a MIPv6 CoA, there is **no** IPv6 CoA involved anywhere.

> no, use an v4-mapped CoA, it's better".

An application on a MN running MIPv6 sees the MN's IPv6 home address,
(HoA) and shouldn't care whether MIPv6 uses an IPv4 CoA to transport the
app's IPv6 traffic to the HA.  

It now seems to me (and I'm saying this because it's just what it
here seems like, no other reason) that you're saying 'CoA' when you
are referring to the address the applications see.  But that is the
MN's HoA, nothing else.

> there's no reason because I don't want to troll.

Because the apps use the IPv6 HoA provided by MIPv6!

> Currently the port numbers aren't in the binding cache.

I don't care where you put them in your implementation.  They have
to be known and remembered.

> bootstrapping would work unmodified if the MN gets an IPv6 address when

???  If the MN is in an IPv4 only network, that seems a bit weird.
Are you proposing that we set up a 6to4 tunnel so we can get a MIPv6
address which we can use as a CoA?  That approach has been discussed,
but has much higher overhead than the current proposal.  See
http://tools.ietf.org/html/draft-larsson-v6ops-mip-scenarios-01

> real IPv6 prefix advertised to it by the HA (that I currently call GW).

Seems to me you're talking about the HoA, then.  The whole purpose of
the current draft is to provide an IPv6 HoA by means of MIPv6.  But
if you insist on calling the HA by the name of 'GW', and calling the
HoA by the name of 'CoA', then it is very hard to communicate.

> MIP4 as a good intent, whatever that may mean for you, good or badly

Oh, I'm not overjoyed about this thread either, thank you.  Especially
if it turns out that the main cause of confusion is using the wrong
terminology.

	Henrik