Subject: [Mip6] Minutes of MIP6 WG meeting from IETF64

From: Basavaraj Patil <[email-masked]>
Date: Fri, 09 Dec 2005 10:10:10 -0600

Minutes of:
Mobility for IPv6 (mip6)
At: IETF64
November 10, 2005 (Vancouver)

Chairs: Basavaraj Patil <[email-masked]>,
        Gopal Dommety <[email-masked]>

Credit for these minutes:
       1. Alper Yegin <[email-masked]>
       2. Nicolas Montavont <[email-masked]>

####################################################

1. WG document status update (Basavaraj Patil)

- Bootstrapping DT has successfully completed their mandate.
  Gerado has been leading the DT. Task is completed.
  3 documents have been produced.
  Problem Statement document.
  Solutions: There are 2 different scenarios addressed. Split and
  integrated scenarios.
  DT is disbanded. All future work will be taken up in the WG ML.
  DT no longer exists.
  Archves will be made publicly available.
 
- Transition DT is active. Work is in progress. DT is quite
  active. They have been having several meetings and produced one
  document. DT is constituted in conjunction with the NEMO WG.
 
- WG documents:
 
 o mn-ident and mip6-auth are approved by iesg since the last ietf.
 o mip6-auth has taken significant amount of time.  It accompanies an
 iesg note, a warning.
 o precfgkbm: completed WG LC, iesg reviewed once, had several discuss
 comments, all addressed. Rev 4 is submitted but lost by the drafts
 editor. Will send to iesg soon.
 o bootstrap-ps: WG Lc completed. recently received several
 comments. This is a ps, we don't need to spend too much time on it.
 o firewalls: several iesg discuss comments, all addressed. ready to
 go back to eisg. 
 o cn-ipsec: has fallen tru the cracks. LC will happen soon.
 o mip6-ikev2: WG LC completed. submitted to AD.
 o adv-api: will send to AD.
   Samita: added a new socket option, and a section on applicability,
   and clarified few points. Addressed all the comments from
   iesg. There will be another rev 6 version right after this ietf.
 
New WG I-Ds:
- location privacy
- bootstrap with dhcpv6
- dual stack mipv6 for hosts and routers
- why auth data suboption is needed
 
8th tahi announcement: See slides
 
Hesham: Can we go to WG LC for the dual stack ps?
Raj: Do we really need a ps, or can we incorporate it as a paragraph into
the 
     solution document.
hesham: Lets discuss on the ML.
vijay: It could be folded into the solution doc as a paragraph or section.
 
--------------------------------------

2a. MIP6 operation with IKEv2 (Vijay Devarapalli)
   I-D: draft-ietf-mip6-ikev2-ipsec (04)

- A few changes have been made to the document
  Refer to slides for changes made.

hesham: There is no reason for hoti and coti. We can do all in
        transport mode. Then we'll have only one transport mode.
vijay: You end up with more headers. Most implementations can use any
        kind of SA.

2b. HA Assignment with IKEv2 (Francis Dupont)

[See slides]

No reason to use any other mechanism for HA assignment.
 
gerardo: You still need to use home prefix on the mobile node to form
         the anycast address.
francis: Yes, you need to find the anycast address one way. You can
         use static config or DNS.
gerardo: There is no way to lookup home prefix.
vijay: Just for HA assignment, this is a very heavy solution. Just use dns.
francis: DNS is not assignment, it is discovery. We don't know if
         discovery is enough. Operator decides which HA to use for the
         service. 
vijay: I'm ok with this mechanism. However it should not be the
         default option.
hesham: DNS lookup is not mutually exclusive. Difference between this
        and dns is you want to do load sharing with anycast address.
francis: You just publish an anycast address, helps with privacy.
hesham: Why do you need a cookie?
francis: 1. against DoS attacks. 2. to be able to reuse almost all
         code of IKEv2.
hesham: Is the cookie signed?
francis: No. It is only for return routability check.
hesham: If the cookie is not crypto generated.....
francis: ???
gerardo: This solution only used for load sharing in the same home
         link. HA assignment in different links dont work.
francis: You can do something with anycast without a real home link.
james: I agree this could be used, and modify dns lookup. There is no
         way to securely update the anycast routing. You need to
         manually configure anycast routing.
francis: I dont see a difffernce between unicast and anycast routing.
kuntal: I don't think it can be used to assign an HA in the access network.

--------------------------------------

3. IPv4 traversal for MIP6 (Hesham Soliman)
   I-D: draft-ietf-mip6-v4traversal (00)

[See slides]

Discussion:
james: Do you think it works for HA to send something periodically?
hesham: Processing wise it won't be as heavy.
james: It is heavier to transmit than receiving.
vijay: It is not possible since firewall will not the traffic pass.
vijay: There are other mechanisms for keep alives. It can be vendor
specific.
 
francis: Do you use the same udp for singaling and traffic, or separate the
port 
         numbers?
hesham: They are the same. Shall we separate?
francis: If you use the same, you get security for both. this can be a good
thing, 
        but a bit expensive.
francis: Btw, you need nat traversal for IKE.
hesham: IKEv2 has NAT traversal. I don't know if we need to solve the
problem for 
        Ike.
 
c.perkins: You didn't say much about dynamic home address assignment.
hesham: This is not to deprecate rfc 3344. We can do the same as in mip4.
The problem 
is, depending on where you are , you might want to use mip6. There is no
need to 
force the people to implement both mip4 and mip6. This is not to replace
mip4.
henrik: If mn with mip6, why should you need to add ipv4 to use mipv4? What
is the 
motivation?
hesham: The idea is that we need one mobility management rptocol, not 2.
 
francis: We should have a competition.
raj: Should we use the nat traversal mechanism that already exists?
francis: NAT traversal also includes mobility support.
hesham: If you are moving and do not have a vpn gateway, do you still use
mobike?
francis: Road warrior case inlcudes nat traversal. You have competition with
something already available.
hesham: I don't think we can rely on ikev2 only, you may not have ikev2.
francis: You already have mobile vpn.
hesham: Not everyone is using mobile vpn.
francis: You need IPsec.
 
vidya: I disagree with francis. Mobike does not give you a permanate
address.
vidya: Do you allow all types of NATs?
hesham: We don't assume protocol translators.
hesham: We allow port forwarding.
 
(boeing): Your model is like the aviation model right now. We live in a
translator 
world. IPv4 aircraft wont change for 20 years.
 
gerardo: MN can also ask for ipv4 and ipv6 home address.
hesham: We had identity in the BU for allocation.
gerardo: In bootstrapping, the HoA is assigned with IKEv2. We could do the
same for 
IPv4.
 
kent: We can support the nat on the HA side dynamically. we can detect and
deal with 
it. 
hesham: We think deploying a NAT is not a plug and play.
 
vidya: Can we really hav NATs in front of HA?
raj: Take it up on the ML. Pascal proposed this.
 
(nasa): Service providers are doing filtering. it gives the same effect.

--------------------------------------

4a. Bootstrapping: Split scenario (Gerardo Giaretta)
I-D: draft-ietf-mip6-bootstrapping-split (01)

 - Scenario
 - Summary of the solution

Hesham: don't understand HoA registration in the DNS

Gerardo: if the HA needs to update the DNS or not.

Hesham; if the option is not there, the HA won't update the DNS.

Gerardo: the optyion is to remove the DNS entry. No option means don't
update.

 - Status update
 - issue 48: load balacing is out of scope of the document

Francis: SRV has priority and weight. you should not update the
         weights to do dynamic assignment.

 - Issue 50: identity in HoA config
 - Issue 51: CGA check

francis: Issue 51 is not related to bootstrapping. If there is a check, it
shall be 
         part of the authorization.

Hesham: isn'"t this the opposite of the bootstrapping: if you go
through AAA, you don't need this. Why you want to know it's CGA?

Gerardo: That's the point. We won't know.

 - Issue 52: HoA auth in DNS update

Hesham: Are you asuming to use IKEv2? Your method allows us to get rid of
        AAA.
....................
    
4b. Bootstrapping: Integrated scenario (Kuntal Chowdhury)
I-D: draft-ietf-mip6-bootstrapping-integrated-DHC (00)

New document made by the DT

 - design gaols and assuptions
 - Solution presentation

Hesham: Distinction between HA and ASP for accounting and using
        something like this for bootstrapping. You should create an
        entity for HA in ASP, because it's a local agent. The HA is
        there because it is closer to the MN.

If you already have 2 HoAs. You chose one for a session and then you
switch ISP. Can you use this HoA in this ISP?

Raj: When you bootstrap,you get a HoA. You keep this HoA for your
     session.

hesham: I though that we tried to avoid changing HoA when you move
networks.

Henrik: Question from the trust case: if I know as MN that my HA is in
my home network. It's difficult to trust a HA which is ad-hoc located.

Raj: It is a transitive trust. You don't have to use this HA.

Alper: Don't see the pb as long as we have MIP authentication.

Kuntal: the MSP can forbid to place HA in ASP.

Henrik: Given the relationship in place, it's ok

Gerarldo: ASM and MSP already ahve a trust relation.

Alper: MN is aware wether he has a HA in ASP or MSP.

Hesham: disagree. the purpose to allocate a certain HA to the MN is
unknown to the MN. The reason does matter, it is ambigous, I don't
understand why we don't distinguish between the two.

Alper: When teh MN asks for a HA, it is aware of which HA it received.

Hesham: no it doesn't know agbout the location, it only knows the
identity.

Alper: We have a flag asking for the location of the HA.

Raj: Continue the discussion offline

Jean-Michel: Why DHCP server is in the ASP?

Kuntal: because it is usually locally where you are. It is the more
pratical situation.

Jean-Michel: So why do you need a DHCP relay?

Kuntal: because the DHCP server may be on a remote link.

Jean-Michel: strange to see that, as the dHCP has infomration from the
home network.

 - Open issues

Francis: if you need something for diamter, go to DHC WG.  I disagree
about RRAO doesn't content MIP6 information. Please re-use existing
mechanisms.

Kuntal: I don't know hwo to process now, but we are aware of it.

Raj: Don't argue where we have to do things.

Francis: Nowhere you have something that says it's NEMO (don't want a
second draft just for NEMO)
....................

4c: Bootstrapping with IKEv1 (Vijay Devarapalli)
I-D: draft-devarapalli-mip6-ikev1-bootstrap (00)
 
greg: Have you looked why they are exprired? becaise they are not secure.
vijay: Hybrid auth is secured.
 
vijay: I don't know why these specs are not standardized.
 
raj: How many people will use ikev1?
combs: The choice is for operators'. We have to propose 2 solutions.
francis: We need to use IKev2 as soon as possible.
raj: Let's take this up on the ML.
   
--------------------------------------

5. Mobility header home agent switch message (James Kempf)
I-D: draft-haley-mip6-ha-switch (00)

[see slides]
 
kuntal: The signal from HA to MN may cause harm. If the HA is going down,
you need to 
        send message to all mobiles, there may be a large number of
        them. It would create a message storm and bring down
        networks. Be very careful. Sometimes it is better not to do
        anything. Don't wake up dormant nodes. Paging is a shared
        resource. Networks go down with this kind of mechanisms.
raj: This is a trade off.
kuntal: If the reason is unfixable, let the binding expire or let the MN
find out 
instead of waking up the mobile. Why do you wake up the mobile?
james: if the mobile is dormant, you have a point.
kuntal: Carriers maintain the session in two box.
james: You are saying that carriers don't require that.
kent: I like the mechanism, agree with kuntal. A good application may be a
prepaid 
mechanism. Unicast a particular mn is ok. In general this is a good idea.
hui: EV-DO is using access channel for paging. Performance has improved.
greg: It is not a bad idea. But concerned about the generic signaling, and
if every 
node will implement this.
james: So, you say we already have a solution.
hesham: Idea of having a generic template to load options is a useful thing.
james: So, you support the idea of generic signalling.
ryuji: I think this is important work. but we have to do more work to
provide this 
functionality. nowadasy there are different types of HAs, like for nemo. HA
must 
return same type of HA.
henrik: I think idea is good. I think kuntal's comment is more about how you
should 
not use it. You can distribute messages to minutes or hours to lower the
load.
raj: There are some concerns. but most people agree that it is a good
feature. We'll 
put this to consensus call on the ML.

--------------------------------------

6. Route Optimization and location privacy using tunnelling agents
(Kilian Weniger)
I-D: draft-weniger-rota (01)

[see slides]
 
raj: Further discussion will be taken up on the list.
francis: There are some other proposals, not for the exactly same scenario.

--------------------------------------

7. Improve communication between mobile nodes   (Yuzhi Ma)
I-D: draft-yuchi-mip6-mntomn-improve (00)

greg: Mip6 is defined for CNs which are also mobile. CN can also be a MN.
There is a 
draft in mobopts on this. I think this is  mobopts work.
 
raj: You should discuss this in mobopts.

--------------------------------------

8. Next steps (Gopal Dommety)
 
[see slides]
 
rajeev: Solutions for location privacy, mobopts is also looking at
that.

######################################################

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