Subject: rfc2292bis: interaction with home address option

From: [email-masked]
Date: Wed, 24 May 2000 17:39:46 +0900

Hello, while thinking about interaction between mobile-ip6 and
	BSD APIs, I came up with the following questions.  I still do not
	have the answer.  If you have any working practice I would like
	to know that.  They can be related to future revisions of rfc2292bis.

itojun

--
when a node A received packet from mobile node B:
packet will carry home address of B in home address option (destination
options header, and care-of address in IPv6 source
- which address should getpeername() return?  home address, or care-of?
	home address sounds like a good default pick, however, some apps
	may need to look at care-of.
- which address should recvfrom() return?
	ditto.
- can we get home address option in IPV6_RECVDSTOPTS?
	it seems like so.  it will have home address of B, not care-of.
- then, how can we get care-of address of the peer?
	(1) new IPV6_RECVxx in rfc2292 advanced API?
	(2) new system call? -> unacceptable

when a mobile node A sends packet to a node B:
A may want to control the use of mobile-ip6.  examples: (1) if A would like
to talk to ubiquitous services like DNS, A may want to use care-of address,
not the home address. (2) IKE (to establish key for mobile-ip6) requires it.
- how can we avoid use of home address?  1-bit flag in setsockopt?
- what is the relationship/interaction with IPV6_PKTINFO?
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Markku Savela <[email-masked]>
Date: Wed, 24 May 2000 13:18:02 +0300 (EET DST)

Just some quick answers about what our code would do now...

> - which address should getpeername() return?  home address, or care-of?

returns home address

> - which address should recvfrom() return?

returns home address

> - then, how can we get care-of address of the peer?

receive UDP in raw mode and dig in? :) (however, the raw mode is hard
to apply to TCP...)

> - what is the relationship/interaction with IPV6_PKTINFO?

Still open issue for me. Eventually, I too need an answer to
this. HTTP is another protocol where one might want to decide whether
to use care- or home-address.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 24 May 2000 19:25:00 +0900

>receive UDP in raw mode and dig in? :) (however, the raw mode is hard

	?? with RFC2292 IPv6 raw socket, this is not possible.
	(if you pass IPv6 header to the userland, that is not RFC2292
	conformant)

itojun

---

From: Markku Savela <[email-masked]>
Date: Wed, 24 May 2000 14:11:55 +0300 (EET DST)

> 	(if you pass IPv6 header to the userland, that is not RFC2292

... promts me to make a query concerning dual IPv4/IPv6 stacks: has
anyone given any thoughts about mapping IPv4 into RFC2292 (+bis)?

One should be able to write new applications using this API alone
(also for IPv4 connections), without any concern about IPv4 or IPv6
(where it is not explicitly required)?

For example, some UDP based services (IKE for example), need to know
the actual destination address that was used in the incoming UDP
packet. In IPv4, the only way to get this was to enable raw mode and
dig it out from the packet. I guess for this special need, the packet
information of RFC2292bis should work for both IPv4 and IPv6?

..which gets me back to original query: wouldn't the source address
packet information contain the care-address in the described scenario?

-- 
Markku Savela ([email-masked]), Technical Research Centre of Finland
Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Steve Deering <[email-masked]>
Date: Wed, 24 May 2000 09:04:27 -0700

>	may need to look at care-of.

Itojun,

On the correspondent node, getpeername() should return the home address
of the mobile node.  This is so most apps can be oblivious to the mobility
of the node to which they are speaking.

Can you give some examples of why an app on the correspondent node would
want or need to know the current care-of address of its peer?

>- which address should recvfrom() return?

The home address.

>	it seems like so.  it will have home address of B, not care-of.

If you really need to receive both addresses for some reason, the care-of
address is the one that should be obtainable only via IPV6_RECVDSTOPTS.
Logically, the IP layer in the correspondent host should swap the received
home address and care-of address before passing the packet to an upper
layer.

>- how can we avoid use of home address?  1-bit flag in setsockopt?

This is just another example of the source-address selection problem (as
discussed in Rich's draft).  When initiating communication, the mobile
host must select one of its valid addresses to use as source address.
The default behavior, if the application or user doesn't care, would be
to use the home address (or one of the home addresses, if there are
more than one).  But an application, such as the ones you mentioned,
can choose to use a different source address, i.e., the temporary
care-of address.  We should already have whatever API function is needed
for the app to specify the source address, so no new flags ought to be
needed.

Steve

---

From: [email-masked]
Date: Thu, 25 May 2000 01:27:28 +0900

>home address and care-of address before passing the packet to an upper

	Yes, I agree that by default only home address should be visible,
	so getpeername() and recvfrom() should see home address only.

	Your suggestion,
	- Swapping received home address option and care-of (in ip6 header)
	  in ip6 layer and
	- Present care-of address in IPV6_RECVDSTOPTS
	is a good candidate (this was one of scenario in my mind), however, we
	need to document it at least.  Otherwise we will get low portability.

	There always are certain applications that needs to peek, or use
	care-of address.  From my limited experience "transparent mobility"
	is not usually useful, and we need "mobility awareness" in many cases.
	The best example is IKE traffic used for mobile-ip6 IPsec key.

>for the app to specify the source address, so no new flags ought to be

	Do you suggest that bind(2) should affect the use of home address
	option?  I'm not 100% sure if bind(2) does enough thing for us.
	If we can assume that we have "home address flag" on every interface
	address we have, then yes, we can do this:
	- If we are in home network, use whatever the user have specified with
	  bind(2).
	- If we are in remote network,
		- If the address specified by bind(2) is marked as home address,
		  use it with mobile-ip6 dance (attach home address option,
		  use some care-of address in IPv6 source)
		- If the address is marked as non-home address, emit packet
		  without mobile-ip6.
	If we take this route, we need a portable way to identify which
	interface address is home address, and which are not.  this should be
	documented somewhere in 2292bis.

	Interaction with IPV6_PKTINFO still confuses me.  I'm unsure about
	interaction between IPV6_PKTINFO and bind(2) if we use both (it is
	not documented in 2292bis-01).  I'm even more unsure about its
	interaction with mobile-ip6.

	Another example of confusion: interface selection.  We have so many
	ways to specify outgoing interface, or scope zone, when we throw packet
	to outside:
	1. sin6_scope_id field in sendto(2)/sendmsg(2)
	2. sin6_scope_id field in connect(2)
	3. sin6_scope_id field in bind(2)
	4. IPV6_PKTINFO sticky option
	5. IPV6_PKTINFO on sendmsg(2)
		(3) to (5) specify source, but if we use link-local source they
		would affect the outgoing interface selection.
	we know (1) overrides (2) in IPv4.  other interactions are not defined.
	FYI, KAME uses the following order (we know this is not in standrd,
	but this was the best we could come up with):
	- IPV6_PKTINFO on sendmsg(2) is the strongest
	- IPV6_PKTINFO on sticky option
	- address specified by basic API on transmission (one-time option, like
	  sendto)
	- address put into pcb struct (sticky, like bind/connect) is the weakest

itojun

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 24 May 2000 09:56:29 -0700 (PDT)

> 	may need to look at care-of.

home address
Do you have an example application that may need to see the COA?

> - which address should recvfrom() return?

home address

> 	it seems like so.  it will have home address of B, not care-of.

We've had some discussion a while back on the topic to what extent
the protocol stack must remove options and not pass them up
to the application. The main issue back then was the jumbogram option.
I think we decided to leave this implementation defined i.e. the stack
might choose to remove the jumbogram option or leave it in place.

So I think in general 2292bis doesn't state (clarly) what happens to
hbh and destination options which the stack actually does some
processing on - are they passed to the application or not; and
if they are passed to the application must the stack leave the option
content exactly in the form it arrived on the wire.

> 	(2) new system call? -> unacceptable

Seems like first we should decide whether it is a requirement of the API
to be able to return this information.
Then we can decide what the mechanism should be.

> - what is the relationship/interaction with IPV6_PKTINFO?

Just to clarify: are you talking about the case when A wants to use
A's COA as the source instead of A's home address?

I assume the bind() socket call can be used to specify the source address
to use.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 24 May 2000 09:58:32 -0700 (PDT)

> information of RFC2292bis should work for both IPv4 and IPv6?

In IPv4 you can get this with the IP_RECVDESTADDR(sp?)
socket option which uses ancillary data just like the IPv6 advanced
API options.

So it seems like overkill to use the IPv6 API mechanisms in this case.

   Erik

---

From: Steve Deering <[email-masked]>
Date: Wed, 24 May 2000 10:01:28 -0700

>	need to document it at least.  Otherwise we will get low portability.

I thought that was documented in the Mobile IPv6 spec (but it's been a
long time since I read it, so I may just be imagining what is supposed
to be there.)

>	The best example is IKE traffic used for mobile-ip6 IPsec key.

Clearly, the apps on the mobile host itself often need to be aware of
their own mobility.  But why should apps on the correspondent node have
to know anything?  And if they do, they should be informed by via their
application-layer protocols, not by polling the IP layer about each peer
to see if it happens to be mobile.

>	option?

bind should affect the choice of source address.  The IP layer is
expected to know which of its addresses are home address.  Sending a
packet on a socket that is bound to a home address, when away from home,
should cause the home address option to be added to the packet before
transmission.  (Note: need to worry about PMTU discovery consequences of
inserting options without application's knowledge.)

>  I'm not 100% sure if bind(2) does enough thing for us.

Yes, the IP layer certainly needs to know which of its addresses are home
addresses.  I've talked about this a couple times at WG meetings, e.g., see
http://playground.sun.com/ipng/presentations/Sep99/PDF/deering-plugnplay.PDF.
One approach is to have some sort of user interface (command, button, or
whatever is appropriate for the type of device) to tell a node "You are
now on your home subnet.  Remember these addresses."  Another approach
might be to have a node look up its own DNS name (which it keeps stored
in non-volatile memory) and consider any addresses that come back that
don't belong to the currently attached subnet(s) to be its home addresses.
This definitely needs to be thought through and written down.

I don't have quick answers to the rest of your questions.

Steve

---

From: [email-masked]
Date: Thu, 25 May 2000 02:22:23 +0900

>long time since I read it, so I may just be imagining what is supposed

	I don't think there's mention about swapping home and care-of
	addresses.  mobile-ipv6-12 page 12 and 32 have some description,
	but they uses "substitute" or "replace", which looks to me to
	overwrite care-of by home address (or the document does not suggest
	the gory dteail).

>to see if it happens to be mobile.

	hmm, I understood.  I may have been confused.

itojun

---

From: [email-masked]
Date: Thu, 25 May 2000 02:15:11 +0900

>Then we can decide what the mechanism should be.

	hmm I see.

>I assume the bind() socket call can be used to specify the source address

	yes, it was about source address selection (and use of mobile-ip6
	options) on node A.  see reply to Steve for details.

itojun

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 24 May 2000 10:49:00 -0700 (PDT)

Itojun,

I don't understand what the requirements are for this case.
On a correspondent IKE can just use the home address of the mobile during
the IKE exchange, right? (The packets will go to the home agent and
be tunneled to be mobile node.)

Is this an issue for the IKE exchange between the home agent and the MN?

> 	address we have, then yes, we can do this:

You can do it even without an added flag.
If the application has bound to a specific IP address (and not in6addr_any)
then that address will be used as the source address (and for TCP connections
there is an implicit "binding" that occurs when the SYN is sent or received -
nothing new here).

Thus if app bound (explictly or implicitly) to a home address and the MN
is not at home, the home address option would be added by the stack.
Otherwise there is no need add it.

This does require that the stack distinguishes between its home
address(es) and COA(s), but I suspect it needs to make that
distinction in any case.

> 	interaction with mobile-ip6.

My assumptions have always been that IPV6_PKTINFO has the same semantics as
bind() in this respect. I guess it would make sense to make that explicit in
2292bis.

> 	- address put into pcb struct (sticky, like bind/connect) is the weakest

Should I just put this order as the recommended order in 2292bis?

   Erik

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 24 May 2000 16:32:30 -0400

> home address and care-of address before passing the packet to an upper

This sort of thing gives us security types hives..

Particularly when it comes to knowing which address is which, if, for
instance, rfc2401-style policy checks could conceivably happen either
before, or after, the swapping...

					- Bill

---

From: Steve Deering <[email-masked]>
Date: Wed, 24 May 2000 14:22:41 -0700

>This sort of thing gives us security types hives..

Yeah, it gives even us aesthetically-sensitive, non-security types hives.

The architecturally clean way to do what Mobile IPv6 does would be
for the mobile host to generate an IPv6 packet with source = home addr,
dest = correspondent addr, and then encapsulate that in another
IPv6 header with source = care-of addr, dest = correspondent addr,
in order to get it past the ingress filters at the foreign site.
Just another example of tunneling.  If it were done that way, the
PMTU discovery issue I parenthetically mentioned earlier would become a
non-issue (we already know how to make PMTU discovery work through tunnels),
and at the receiving correspondent host, the outer header would stripped
off (normal tunnel endpoint decapsulation) and the original packet with
the home address as source would be delivered to the receiving upper layer.

I presume the Mobile IP WG decided to do it differently to avoid the
overhead of a full encapsulating header.  But perhaps we can think of the
required process as doing an encapsulation, as described above, and then
performing a weird, mobile-IP-specific type of header compression (inserting
an option, moving some addresses, discarding the outer header) at the
sender, and then reversing the process at the receiver.  Does that help?
I didn't think so.

Steve

---

From: [email-masked]
Date: Thu, 25 May 2000 10:38:58 +0900

>Is this an issue for the IKE exchange between the home agent and the MN?

	sorry again I was confused.  IKE traffic for mobile-ip6 key does
	not carry home address option.  this is mobile node who needs to use
	care-of as source.  correspondent node do not need tricks.
	(mobile-ipv6-12 10.2)

>address(es) and COA(s), but I suspect it needs to make that

	I meant kernel internal flag by "home address flag", which may or may
	not be exposed through the API.
	kernel needs to somehow distinguish its home address from its care-of.
	I think my wording was not clear enough.

>Should I just put this order as the recommended order in 2292bis?

	if there's no conflicting opinion on this, I'm happy with that.

itojun

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 25 May 2000 18:14:36 +0900

Note: I changed the subject.

>>>>> On Wed, 24 May 2000 10:49:00 -0700 (PDT), 
>>>>> Erik Nordmark <[email-masked]> said:

> bind() in this respect.

I think you two are actually comparing the semantics of sin6_scope_id
and the semantics of IPV6_PKTINFO, right? Then, I think that those two
are different, at least based on the model described in
draft-ipngwg-scoping-arch-01.txt (or
draft-ietf-ipngwg-scoping-arch-00.txt...01 seems to be officialy
unpublished).

Since links are broader scope than interfaces, IPV6_PKTINFO
(conceptually) imposes stronger restriction than sin6_scope_id.

For example, suppose that two interfaces ne0 and ne1 belong to a same
link (and the link only consists of those two interfaces). Then
consider the following combinations:

1. sin6_scope_id = 1, without IPV6_PKTINFO
   (where 1 is the link identifier that contains ne0 and ne1)
2. sin6_scope_id = 0, with IPV6_PKTINFO(ne0)
3. sin6_scope_id = 0, with IPV6_PKTINFO(ne1)

In my understanding, the outgoing interface for each case is as
follows:
1. ne0 or ne1. It would depend on implementation, or the status of
   runtime routing table.
2. ne0
3. ne1

>> would affect the outgoing interface selection.

To make sure: conceptually, all scoped sources (including site-locals)
would affect the outgoing interface, when the node is multi-zoned.

>> - address put into pcb struct (sticky, like bind/connect) is the weakest

Basically agreed (actually I implemented the above order :-), but I
think we need some additional restrictions. For example,

  if a scoped address is specified by bind(2) and the outgoing
  interface specified by IPV6_PKTINFO does not belong to the zone
  determined by the bound address' sin6_scope_id field, the kernel
  should not send the packet and return an error.

However, I'm not sure these additional rules should be noted in
rfc2292bis.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Sat, 27 May 2000 17:07:39 +0200

In your previous mail you wrote:

   	to know that.

=> I have both!

=> home address with a getsockopt() (or a new system call) which returns
the real destination address. Same for getsockname() because IKE needs
a way to know the real source address, ie ID-12:
    -  The mobile node MUST use its care-of address as the Source
       Address of all packets it sends as part of the key management
       protocol (without use of Mobile IP for these packets, as
       suggested in Section 10.1).
For the correspondent node things should be more transparent but:
 - home agents are correspondents
 - symetry argument
then I'd like to get both getsockopt() in the new standard, of course
results should be sockaddr_in6 structures and be the same than from
`genuine system calls when there is no mobility stuff.

=> same problem but it is enough to have a getsockopt() for connected/bound
sockets because the mobility stuff uses addresses only. The answer is
the home address.

=> if the new I-D or RFC is clear enough about processing of home address
option processing then we'll know the answer. If per instance it asks for
an address swap (my favourite) then the destination address in the header
will be the home address and the address in the option the care-of,
recvfrom() will return the home address (good) and the care-of will be
accessible with IPV6_RECVDSTOPTS (good again). As a side effect we'll
know how to compute the AH message digest (:-).

=> (2) IKE is why I've already added a getsockopt() for this.
For (1) I have a configuration flag in the mobility management tool
in order to consider local nodes (ie nodes on the same link/sharing
same prefixes) as correspondents or not:
 - with the first option all new communications will go through the home
   (remote) agent
 - with the second option open connections with local nodes will be
   broken by movements.
There is no good choice then users can say what they like. I believe
you'd like a way to override the first choice for "smart" applications
(this is fine for me).

=> see above

=> I believe only special getsockopt() should look at what really happens
with mobility stuff. Other parts of the API should be as transparent as
possible.

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Sat, 27 May 2000 17:29:47 +0200

=> I agree!

=> I know no example but there is at least one (IKE) on the mobile node
which would need to know the current care-of address.

   
=> Logically but not (yet?) written down in the IPv6 mobility document!

=> Itojun's concern a bit different, he asked how the application can get
the care-of address. Today racoon (KAME IKE deamon) does:
 - open a new UDP socket
 - connect it to the destination
 - get the selected source address by getsockname()
 - use it (ie in bind() system call) for IKE exchange with the remote party
   with security processing disabled (ie. IKE has its own protection).
I have changed it into:
 - open a new UDP socket
 - connect it to the destination
 - get the selected real source address by a new getsockopt() which gives
   the care-of address (not the home address) on a mobile node in visit
   and the same answer than getsockname() in other cases.
And for IKE exchange I disable mobility processing (ie home address stuff)
and security processing.
Then only things I use are:
 - interaction between source selection and mobility (ie use the home address)
 - a way to get the current care-of address

Regards

PS: the rationate (according to draft-ietf-mobileip-ipv6-12.txt) again:
    -  The mobile node MUST use its care-of address as the Source
       Address of all packets it sends as part of the key management
       protocol (without use of Mobile IP for these packets, as
       suggested in Section 10.1).
Example: the mobile node boots in visit and needs to send an
authenticated binding update for home registration to the home agent.
(boots -> no established security association, authenticated -> needs
to setup a security association before, home registration -> the home agent
doesn't know the binding and can't reply to the home address)
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------