[Mip6] IETF67: MIP6 WG meeting minutes

[Basavaraj Patil <[e-mail]>]

Minutes of:
Mobility for IPv6 (mip6)
At: IETF67 
November 7th, 2006 (San Diego, USA)

Chairs: Basavaraj Patil <[e-mail]>
    Gopal Dommety <[e-mail]>

Credit for these minutes:
1. Ahmad Muhanna (amuhanna at nortel dot com)

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

1. Agenda, WG status update

Raj presented the agenda and gave an update on the WG status including
WG documents.

- Charter has been revised to reflect more accurately what the WG is
currently doing. In other words, it reflects the work being done.
- 2 RFCs have been published 4584 and 4640.
- New WG documents that have been incorporated:
  1.    DHCP options for bootstrapping
  2.    RADIUS Mobile IPv6 Support, RADEXT charis agreed to do under mip
- MIP66 IKEv2 I-D in IETF LC
- 4 drafts Completed WG LC.
  o dsmip
  o whyauthdataoption
  o aaa-ha
  o bootstrapping split

- Bootstrapping documents that will go to WGLC shortly:
  o bootstrapping Integrated scenario
  o mip6-hiopt
- HA switch work in progress
- HA reliability Work in progress.

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

Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture
   I-D: draft-ietf-mip6-ikev2-ipsec-06
   Vijay Devarapalli

- Vijay presented Mipv6 with ikev2 and RFC4301
- Jari asked if the security chair reviewed the issue that Vijay
  talked about 
- Gerardo pointed that we need a clear requirement for AAA in relation to
IDi
- Jari expressed his view saying that he does not think it is a
  conflict for both MIP6 and MOBIKE to manage the tunnel. In other
  words suggested that in case of the presence of another protocol to
  manage IPsec use it. For example MOBIKE can be used while MIP6 is
  there but not managing the IPsec tunnel.
- If HA is assigned dynamically, the PAD needs to be also dynamically
  populated. 
- Hesham, asked a question why do we need to specify how to populate
  the shared key in the mip6ikev2.
- Jari said the fact that it is not described somewhere else does not
  mean that we do not need to describe it.
- Jari answered Stefano's question by suggesting that he wants to have
  some 4301 expert to look into this issue.

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

MIP6 support for DS hosts/routers
   I-D: draft-ietf-mip6-nemo-v4traversal-02
   Hesham Soliman  

- Hesham Soliman presented nemo v4traversal, allows MN to bind its CoA
  to any HoA or vice versa. Also support for NAT.
- George, this case is really unlikely to be a real deployed setup and
  addressing does not seem necessary.
- Vijay, we do not need this mechanism. When you have HA and trying to
  make it reachable.
- Ryuji expressed his views and that what we are trying to address
  here is to allow the HA to dynamically configure this setup.
- Jari, thinks it is not an important case and we do not need to
  worry about it. 
- Raj thinks there is no need for the dynamic detection of NAT.
- Hesham mentioned that he will confirm on the list the decision to
  reject the dynamic discovery of NAT.
- Vijay expressed his views on the Authors section, he thinks that
  there should be an authors section to be added to the abstract.

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

AAA Goals for Mobile IPv6
   I-D: draft-ietf-mip6-aaa-ha-goals-03
   Gerardo Giaretta

- Hesham, said the reason we moved to Goals instead of requirement,
  that we do not need to express SHOULD vs. MUST, etc.
- Hannes, said requirement need to be used with SHOULD in order to be
  clear in this respect.
- Hesham, asked if Gerarad wants to refer to RFC4285 or not?
- Raj : this is one document in mip6 which intends to capture all
  AAA requirements. Why the current requirement is not sufficient?
- Gerardo said that he needs a mechanism for the bootstrapping. It
  makes sense to add additional requirement to address the RFC4285.
- Alex, presented a comment from someone else (did not get the name
  from Alex) saying that he/she recommends not to add requirement for
  RFC4285 because IPsec is already there.
- Gerardo mentioned that he wants to add requirements for RFC4285 not
  just because he likes this RFC.
- Kuntal said, RFC4285 is used by people who use MIPv6 and we have an
  opportunity to add these few requirements now.
- Hesham, what is the impact of adding the requirements vs. not adding
  them. 
- Hannes, said in I-D draft-ietf-dime-mip6-split-01 the DIME WG wants
  MIP6 WG to identify the requirements clearly.
- Hesham said do we have a draft already for this or not.
- Gerard said no draft.
- Hannes said, we need to have a draft to capture clearly the goals
  and requirements.
- Jari said he thinks adding RFC4285 requirements will be another 2 months.
- Raj answered that these additional requirements from AAA prospective
  is not much to do.
- Jari, mentioned similar cases took too much time to add.
- Raj said we can at the appropriate time ask for consensus.
- Vijay said would we like to have a bootstrapping solution for RFC4285.
- Raj asked for the people who would like to see requirements for
  RFC4285 in the AAA goals and requirements draft
- Raj said the number (get the numbers from Raj, How many were for but
  5 against) for and those against, the question will be posted on the
  mailing list for further consensus.

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

Home agent reliability protocol update
   I-D: draft-ietf-mip6-hareliability-00
   Ryuji Wakikawa

- Ryuji presented HA Reliability Protocol (HA switch message).
- Kent: Did you consider RFC4285 and if the DT would consider RFC 4285
  for the switch message. Ryuji responded no and will consider the RFC
  later. 
- Jari expressed his concern about transferring the IPsec state during
  the switch process.
- Vijay said that there is a minimum state of the IPsec, some state
  which authenticate the MN, etc.
- Jari asked how these different HA are configured
- Hannes, have you socialized this idea with the security AD¹s.
- Kuntal said that transferring IPsec state is already done in the
  industry and we need to keep the IPsec option there.

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

Experimental and vendor specific messages
   I-D: draft-devarapalli-mip6-vsm-01
   I-D: draft-devarapalli-mip6-experimental-messages-00
   Vijay Devarapalli

- Vijay presented Experimental and Vendor Specific messages:
- Raj confirmed that addressing the Vendor Specific messages already
  covered in the MIP6 charter.
- Kuntal asked what happened if the MN sends these options and the HA
  does not understand.
- Vijay: HA may ignore and process the rest of the message.
- Raj asked Jari if we need to ask the group to accept this for a work
  item or not.  
- Raj said that he recommends accepting this as a working item and
  people who have objection can post their comment on ML.
- Kuntal, asked again what happened if the HA does not understand the
  option, what would happen.
- Vijay, HA ignore or when need to do some action there is a process.

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

Firewall traversal: Design choices
   I-D: draft-thiruvengadam-nsis-mip6-fw-05.txt
   I-D: draft-qiu-mip6-friendly-firewall-01.txt
   Hannes Tschofenig

- Hannes presented MIPv6 firewall Traversal Design Consideration:
- Vijay, as long as everything is done in MH, it should be fine.
- Hannes: what do you mean with fine.
- Hannes: Some of the proposals use these hashing mechanism that Vijay
  asked about. 
- Hesham every protocol has to have its own firewall solution. Either
  make someone change the configuration, or say the MIP does not work
  for that MIP.  
- Hannes answered as follows: it depends on the guidelines of the
  firewall admin (I guess).
- Hesham pointed out that the problem does not pretend to MIP only. In
  other words, we need a general solution rather defining a protocol
  specific solution; in this case MIP6.
- Raj : that the current charter that we need to come up with a
  document to explain how MIP6 will work with a firewall. But we need
  to look if there is a generic solution to start with.
- Hesham said that if we need this we need to add some requirement to
  whatever solution is being done rather than reinventing the
  wheel. Hannes agreed.
- James Kempf said that he does not understand what Hannes is trying to do.
- Hannes asked if Jim has read the Problem statement RFC, he also
  tried to explain the problem but still Jim does not get the issue.
- Hesham commented that PS stated the fact about Firewall behavior
  anyway and nothing is new.
- Yaron said that he did not read the PS RFC, he also said that he
  sympathized with Hesham position but he said that we need to have a
  solution to address MIP6 but not to go through redesign the firewall
  again. He said that FW is there for a reason.
- Hesham asked why a generic solution wo¹nt work? No answer.
- Raj mentioned that we have it as part of the charter and we need to
  look into a generic solution but we still need to address MIP6 with
  FW, will present on the ML and go from there.

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

Proxy Mobile IPv6 Discussion
   I-D: draft-sgundave-mipv6-proxymipv6-00
   I-D: draft-chowdhury-netmip6-01
   Sri Gundaveli/Kuntal Chowdhury

- Gopal, presented Proxy MIP6 overview and ML discussion summary
- Brief background first and then open the floor for two authors
- James said that saying mobility across access router is Local
  Mobility Management.
- Kuntal mentioned that using PMIP could be used for whatever
  reason. i.e. Local or Global.
- James said that  we need to keep carrier¹s competition.
- Samita asked the question what mobility across administrative
  domains means.  
- Gopal answered that between different admin domains.
- Hesham said that we need to address it directlyŠ.
- Raj said that PMIP is a direct extension of using the MIP6 client on
  the MN to the Access Router.
- Jari said they are similar despite some differences (PMIP & NetLMM
  DT draft) 
- Vidya said that they (PMIP and NetLMM DT draft) are solving the same
  problem. It is not a mismatch with what Netlmm WG has been doing.
- Jari asked for a consensus if the WG needs to see one solution. The
  clear consensus was for one solution rather than two. 


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