Sorry for the late reply. Here is a little text I proposed to add:
" A mobile node has two addresses - a permanent home address and a care-of address (CoA), which is associated with the network the mobile node is visiting. When acting as transmitter, a mobile node sends packets directly to the other communicating node, without sending the packets through the home agent, using its permanent home address as the source address for the IP packets. This is known as triangular routing. In this case, the ALTO server discovered by the CoA would be used to get the transmission guidance. However, it still uses the ALTO server discovered by its home address or home agent address to get guidance to retrieve content from content sources in the network. The foreign agent could also employ reverse tunneling by tunneling the mobile node's packets to the home agent, which in turn forwards them to the communicating node. This is needed in networks whose gateway routers check that the source IP address of the mobile host belongs to their subnet or discard the packet otherwise. In this case, the ALTO server discovered by the mobile node's home address or home agent address would always be the right choice. If an end host uses proxy to access the network, such as in a company which uses VPN tunnels to connect different sub-divisions in different locations, the proxy IP address should be used for the ALTO server discovery instead of the end host's IP address. In general, according to the data path, the client's IP address/agent's IP address which directly connect and route the client's data to/from Internet should be used for the correspondence ALTO server discovery." Does this make sense? -Haibin > -----Original Message----- > From: Scharf, Michael (Michael) [mailto:[email protected]] > Sent: Thursday, June 21, 2012 4:18 PM > To: Songhaibin > Cc: [email protected] > Subject: RE: [alto] ALTO discovery in roaming scenario > > Haibin, > > Can you please explain how the scenario you describe is different to a normal > NAT middlebox? > > Regarding NAT, the draft right now states that there are various methods to > find > out the right IP address: > > A client can have several candidate IP addresses that it may use for > the discovery process. For example if it is located behind a NAT, a > private and a public IP address may be used for the discovery > process. It depends on the deployment scenario which of the IP > addresses is the correct one. Thus it is out-of-scope of this > document to specify how exactly the client finds the right IP > address. However in the following we list methods that may be used > in order to determine these candidate IP addresses. Generally in P2P > environments peers already have implemented mechanisms for NAT- > traversal. This includes proprietary solutions to determine a peer's > public IP address, for example by asking a neighbour peer about its > record of the own IP address. Non-proprietary solutions that are > favorable include the Session Traversal Utilities for NAT (STUN) > [RFC5986] protocol to determine the public address. If the client is > behind a residential gateway another option may be to use Universal > Plug and Play (UPnP) [UPnP-IGD-WANIPConnection1] or the NAT Port > Mapping Protocol (NAT-PMP) [I-D.cheshire-nat-pmp]. > > > What text do you suggest to add to that? > > Thanks, > > Michael > > > > -----Original Message----- > > From: Songhaibin [mailto:[email protected]] > > Sent: Thursday, June 21, 2012 5:02 AM > > To: Scharf, Michael (Michael) > > Cc: [email protected] > > Subject: RE: [alto] ALTO discovery in roaming scenario > > > > Please imagine a gateway/proxy based network access, the ALTO > > client is the end host, but actually the IP address for > > gateway/proxy which connect the end host to the network > > should be used for ALTO server discovery. The change of > > end-host IP and gateway/proxy IP is independent somehow. I > > hope this clarification helps. > > > > BR, > > -Haibin > > > > > -----Original Message----- > > > From: Scharf, Michael (Michael) > > > [mailto:[email protected]] > > > Sent: Wednesday, June 20, 2012 8:07 PM > > > To: Songhaibin > > > Cc: [email protected] > > > Subject: RE: [alto] ALTO discovery in roaming scenario > > > > > > Haibin, > > > > > > The draft already states: > > > > > > o A change of the IP address at an interface > > invalidates the result > > > of the ALTO server discovery procedure. For > > instance, if the IP > > > address assigned to a mobile host changes due to host > > mobility, it > > > is required to run the ALTO server discovery > > procedure for the new > > > IP address without relying on earlier gained information. > > > > > > Could you please explain what text is missing in the draft, > > and what > > > technical solution you suggest? For instance, if the mobile network > > > uses "Proxy Mobile IP"? > > > > > > My understanding is that in reality roaming/normadic use results in > > > either of two > > > possibilities: > > > > > > (1) There is a change of the IP address of the mobile host. > > This case > > > is already explained in the draft. > > > > > > (2) The IP address of the mobile host does not change. > > Then, the host > > > remains in the same IP subnet, and thus the ALTO discovery > > result is still valid. > > > > > > In both cases, the current text in the discovery draft > > seems to be just fine, right? > > > > > > Thanks > > > > > > Michael > > > > > > > > > > -----Original Message----- > > > > From: [email protected] > > [mailto:[email protected]] On Behalf > > > > Of Songhaibin > > > > Sent: Monday, June 18, 2012 1:22 PM > > > > To: Songhaibin; Richard Alimi > > > > Cc: [email protected] > > > > Subject: Re: [alto] ALTO discovery in roaming scenario > > > > > > > > I would like to dig this from the tomb and see how the WG > > would like > > > > to solve the ALTO discovery in the roaming/nomadic > > scenario. I would > > > > also like to see it in the ALTO server discovery document. > > > > > > > > -Haibin > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: [email protected] [mailto:[email protected]] > > > > On Behalf > > > > > Of Songhaibin > > > > > Sent: Thursday, March 29, 2012 8:34 PM > > > > > To: Richard Alimi > > > > > Cc: [email protected] > > > > > Subject: Re: [alto] ALTO discovery in roaming scenario > > > > > > > > > > Hi Rich, > > > > > > > > > > I think your proposal makes sense. The wikipedia document > > > > > http://en.wikipedia.org/wiki/Mobile_IP provides some links > > > > to relative > > > > > RFCs. We may find details in these RFCs. I will also try to > > > > read them. > > > > > > > > > > BR, > > > > > -Haibin > > > > > > > > > > ________________________________________ > > > > > From: [email protected] [[email protected]] on > > > > behalf of > > > > > Richard Alimi [[email protected]] > > > > > Sent: Thursday, March 29, 2012 8:09 PM > > > > > To: Songhaibin > > > > > Cc: [email protected] > > > > > Subject: Re: [alto] ALTO discovery in roaming scenario > > > > > > > > > > On Thu, Mar 29, 2012 at 12:26 AM, Songhaibin > > > > <[email protected]> > > > > > wrote: > > > > > > Hi Rich, > > > > > > > > > > > > Thank you for the discussion. See inline. > > > > > > > > > > > > ________________________________________ > > > > > > From: [email protected] [[email protected]] > > > > on behalf of > > > > > > Richard > > > > > Alimi [[email protected]] > > > > > > Sent: Wednesday, March 28, 2012 11:57 PM > > > > > > To: Songhaibin > > > > > > Cc: [email protected] > > > > > > Subject: Re: [alto] ALTO discovery in roaming scenario > > > > > > > > > > > > On Mon, Mar 19, 2012 at 4:28 AM, Songhaibin > > > > <[email protected]> > > > > > wrote: > > > > > >> Hi, > > > > > >> > > > > > >> The indicated by the subject, which is perhaps not fully > > > > solved in > > > > > >> the discovery > > > > > draft, I guess at least the following scenarios should be > > > > considered. > > > > > As I'm not an expert on roaming technology, please correct > > > > me if you find I am wrong. > > > > > >> > > > > > >> (1) The ALTO client has left its home network, and its > > > > IP address > > > > > >> is dynamically > > > > > assigned by the current network provider (through DHCP or any > > > > > other method), but the ALTO client still uses its home agent to > > > > access the > > > > > Internet. In this case, the ALTO server resided in its home > > > > > network should be the right ALTO server to be discovered. > > > > > >> > > > > > >> (2) The ALTO client has left its home network, and its > > > > IP address > > > > > >> is dynamically > > > > > assigned by the current network provider, and the ALTO > > > > client uses the > > > > > foreign agent to access Internet or uses its IP address > > directly > > > > > to access Internet. In this scenario, the ALTO server resided > > > > in the current network should be the right one. > > > > > And the existing discovery mechanism works in this scenario. > > > > > >> > > > > > >> (3) If the ALTO client has a persistent IP address when > > > > > >> roaming, and it uses > > > > > home agent to access Internet, but make large data route to the > > > > > foreign agent directly (optimized routing mode). In this > > > > scenario, the > > > > > ALTO server resided in the current network should be the > > > > right one to > > > > > be discovered. However, if it does not adopt the > > optimized routing > > > > > mode, the ALTO server in the home network should be the > > right one. > > > > > >> > > > > > > > > > > > > I'm not familiar with the technologies backing this, but > > > > what entity > > > > > > decides the route that a particular packet will take? Is this > > > > > > DPI living in the network where the client is > > roaming? Or is it > > > > > > some entity on the client itself? > > > > > > > > > > > > [Haibin] No, it is not DPI based. Although I'm not an > > > > expert on this > > > > > > either, but I > > > > > think in the mobile IPv6 scenario, the decision is made through > > > > > the negotiation among the mobile node, home agent, and other > > > > correspondent nodes. > > > > > > > > > > > > > > > > Thinking about this at the high level, If the mobile node > > > > is involved > > > > > in the negotiation, then it seems like it could work like the > > > > > following for this case: > > > > > (1) Discover an ALTO Server using the home agent (same as case 1 > > > > > above) > > > > > (2) Discover an ALTO Server using the current network (same > > > > as case 2 > > > > > above) > > > > > (3) When it comes time to apply the ALTO information, apply the > > > > > correct set depending on the routing for that > > particular request. > > > > > > > > > > Is that compatible with whatever technologies are used for > > > > these scenarios? > > > > > > > > > > Details on how this works and the negotiation actually > > takes place > > > > > would be useful. > > > > > > > > > > Rich > > > > > > > > > > > BR, > > > > > > -Haibin > > > > > > > > > > > >> (4) (this one is not about roaming) Assume in a big > > > > company which > > > > > >> has a few > > > > > branch offices in different locations, and VPN tunnels > > are used to > > > > > connect these branch offices, employees use one proxy to access > > > > > Internet. Then the ALTO server discovery should be based on the > > > > > proxy's IP address instead of the user's IP address. It > > > > also applies > > > > > to other similar scenarios when end-hosts using proxies. > > > > > >> > > > > > >> It might not be a problem when doing third party > > discovery, but > > > > > >> have to > > > > > consider when doing the discovery by the end-host itself. > > > > > >> > > > > > >> BR, > > > > > >> -Haibin > > > > > >> _______________________________________________ > > > > > >> alto mailing list > > > > > >> [email protected] > > > > > >> https://www.ietf.org/mailman/listinfo/alto > > > > > _______________________________________________ > > > > > alto mailing list > > > > > [email protected] > > > > > https://www.ietf.org/mailman/listinfo/alto > > > > _______________________________________________ > > > > alto mailing list > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/alto > > > > > > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
