• Split Scenario: MSA and MSP are different entities


• HS: In the roaming scenario, is the HA assigned by the local network?


• GG: Yes, the HA may be assigned by the local network;


• HS: Do I lookup home.com or visiting.com?


• GG: visiting.com;


• HS: trying to understand the purpose of this HA


• GG: needed to solve the roaming case


• HS: this is not just a roaming case; there is also a case where the HA service is provided by an application provider, maybe in another network, or in the home network


• GG: this scenario is the same as the split scenario; while this is not roaming for network access, it is roaming for mobility service


• HS: the split scenario seems to be referring to roaming


• GD: Are you referring to dynamic HA assignment?


• HS: No, only the location of the HA


• HS: If this is not a roaming scenario, and I dont have an AAA server, can I use certs and use this solution?


• GG: Not addressed by this scenario, but addressed by the solution


• GG: MSA only authorizes the service; does not assign HA or HoA


• HT: Address is assigned by local network; HA assigned by home network


• HS: This is not an issue. Address can be assigned by local network; authorization does not rely on the HoA


• BP: Take it on ML



• Presentation continues HA address discovery (DHAAD, DHCP, DNS); bootstrapping using EAP and public keys; HoA assigned using IKEv2


• FD: Bad interpretation of what IKEv2 configuration is for; provides no validation; it is okay to use it to update DNS


• GG: We have used a new attribute to use for auto-configured HoAs to be used in creation of the child SA


• JA: Is this auto-config happening often or only once?


• GG: only once, upon bootstrap; SA depends on the lifetime of the SA


• AP: pre-configuring prefix is not bad; DNS also requires home.com to be pre-configured


• DT: just another option;


• AP: Anycast can be used for load balancing


• JK: What protocol does that?


• AP: nothing



• Presentation continues HoA registration with DNS;


• HT; A draft is present to link the components to Diameter


• EN: Today, DHCP server does DNS updates; that is the right way to do it; it may be an option to have the HA do it; it should not preclude the MN from doing it using DHCP or whatever, if it wants to


• GG: MN only requests HA to do it using the DNS Update mobility option


• Name?: Is dynamic HA assignment included in the integrated scenario?


• DT: No; DNS can do dynamic HA assignment


• ?: that doesnt do load balancing or other scenarios


• BP: Take it on the ML


• ??: If you use DNS to look up the HA address, is the request sent by the local network or home network?


• GG: by definition, the split scenario doesnt address HA assignment in the local network


• SC: Not very clear if AAA is a requirement for this solution or not


• GG: Not a req.; either AAA or certs can be used; e.g., IKEv2 w/EAP or IKEv2 w/certs can be used

• 2 Major Issues


• 1 RFC3775 & 3776 describe SPD and SAD configs assuming MH and ICMP protocols as selectors; this makes the need for per-interface SPD; 2401bis proposes more granular selectors should we make the use of this a MUST?


• FD: there are 2 reasons why this should not be a MUST you cant assume protocol selectors are available everywhere; SHOULD is good; implementers should have the choice of doing one or the other


• VD: How about if it is a MUST on the HA alone? MNs that do support it can use it


• FD: Use recommend, not MUST


• HS: If all ICMP is protected, there is no issue


• JA: Why is this a problem? If this is using IKEv2, and it uses 2401bis, what is the problem?


• VD: 2401bis does not say these selctors are a MUST


• JA: If you want to do the per-i/f SPD, not sure if you have to say all of it is supported


• Presentation continues Major issue 2 packet formats not meant to support all possible ipsec configs; detailing tunnel mode will bloat the draft


• HS: For HoTi and CoTi, why not tunnel the packet with a transport mode SA on the outer header?


• VD: that can be done


• HS: why not change 3775 to accommodate that?


• VD/BP: May be; send email on the ML


• FD: This is explicitly prevented in 3775 for good reason;

• Scenario 1 – v4 access network; v6 home network;


• 2 same as 1, but MN is behind a NAT


• 3 MN wants both v6 and v4 sessions


• 4 HA does not have a v4 address; connecting a v4 network and v6 network not being addressed; nothing mobility related here;


• NAT traversal is in the scope


• FD: Do you want just re-addressing or full mobility with RO and everything?


• VD: we havent come to that yet;


• BP: Scope of the design team has been limited to a small set of scenarios to address immediate deployment scenarios


• FD: problem is not to just get solutions; need to select good solution


• AP: When mip4 already solves the issue of using IPv4 HoA, why solve this here?


• VD: doesnt make sense running mip4 and mip6 at the same time; lot of issues explained in the dsmip draft

• Signaling overheads of running mip4 and mip6 at the same time


• AP: why provide session continuity for v4 when tunneling in v6?


• HS: still a valid problem


• HS: problem providing reliable service


• DTh: Is it only an efficiency issue? Or more?


• HS: Both efficiency and connectivity; Erratic connectivity; optimized mobility management not possible


• DTh: It does work; just not efficient enough


• GT: optimization becomes necessary here


• GDa: Is there any spec on v4-v6 transition?


• DT: There is GRE


• Presentation continues; Solution suggestions;


• HT: NAT traversal work has been done for ikev2, ipsec


• AP: also done for mip4


• HS: ok. Henrick is on the DT


• AP: binding a v4 address to a v6 address – isn’t that part of 6-to-4 tunneling?


• HS: yes, but without anycast, this is a one-way solution; depends on how people deploy it

• Address privacy and location privacy


• FD: HoA is not visible when BUs are protected, HoA is not visible


• RK: If BU is protected and HoTi and CoTi are used, it can be protected


• BP: Now that Mobopts has done the work, maybe the WG should take it up and publish as informational


• EN: those who are interested in this space can attend the Alien bof.

• BP: Reliability is a WG charter item and there are several solutions addressing this at the present time


• Questions about HA allocation raised by James Kempf. There are some concerns regarding this I-D and the solution being discussed in bootstrapping.


• Vidya N. had concerns about the fact that an HA could detect failures faster than an MN. It should be the other way around.

• Motivations for this I-D presented. Partial and full recovery mechanisms specified.

• This protocol was designed based on the needs expressed by Connexion for addressing their problem scope. But can be used for HA reliability as well.

• James said that this draft proposes a mechanism that is needed by operators deployoing MIP6. They need a mechanism by which they can shutdown an HA gracefully while ensuring that the MNs are switched to other HAs.

• GG: On 120-ms RTT.. does handover delay include movement detection delay?
  A: Yes, we are sending high frequency RtrAdv. It does not include LL handover delay. It also does not consider delay that normal IPv6 autoconf would require. We use optimistic DAD.

• Several solutions to address the problem of securing the HA list presented.


• JA: Solution 2-SEND". What is the 2nd issue that will not be resolved?

A: The frequency is high. So if multiple HAs send RA frequency,..

• JA: I'm not sure I agree. Frequent RAs are for the host. if the home link has hosts, it makes sense to have those RAs. If the HAs are on the same link, there's no need for high frequency.


• EN: It might even be possible, even if you do have hosts and want 30ms beacons, have those RAs not include information updates, HA list, SEND stuff.

• Application interface to exchange mobility information with Mobility subsystem

I-D: draft-momose-mip6-mipsock-00

Chairs aked that the WG should take a look at this I-D and provide feedback to the authors.


• Care-of Address Test for MIPv6 using a State Cookie

I-D: draft-dupont-mipv6-rrcookie-01

The idea is to use a state cookie as in SCTP and IKE. SCTP explanations are very good. No state creation on CN, so no DoS problems with many BUs. There are IANA considerations and hence publishing this as experimental is one possible way forward. In MIPSHOP, Jari found a nice way to solve it.

HS: Hesham Soliman
GG: Gerardo Giaretta
GD: Gopal Dommety
BP: Basavaraj Patil
JA: Jari Arrko 
FD: Francis Dupont
AP: Alex Petrescu
JK: James Kempf
DT: Design Team
DTh: Dave Thaler
HT: Hannes Tschofenig
EN: Erik Nordmak
VD: Vijay Devarapalli
SC: Samita Chakrabarti
GT: George Tsirtsis
GDa: Greg Daley
RK: Rajeev Koodli
VN: Vidya Narayanan