[Mip6] MIP6 WG meeting minutes from IETF66

[Basavaraj Patil <[e-mail]>]

Minutes of: Mobility for IPv6 (mip6) WG
At: IETF66
July 13, 2006 (Montreal)

Chairs: Hesham Soliman ([e-mail])
    Vijay Devarapalli ([e-mail])

Credit for these minutes:
       1. Gabor Bajko ([e-mail])
       2. Brian Haley ([e-mail])


Vijay Devarapalli and Hesham Soliman chairing the meeting on behalf of
Basavaraj Patil and Gopal Dommety

1. WG document status
----------------------
 - 3 RFCs published RFC 4487, 4449, 4295
 - 2 in RFC Ed queue (bootstrapping and mip6 api extensions)
 - 2 in Last Call
 - 2 in AD evaluation

2. Charter Discussion
---------------------
Jari - Proposed content for the rechartering. Scope: to align the charter
description with the work the wg is already doing. Taking on board new
work not necessarily the intention.

Gerardo - Should bootstrapping cover auth option also?

Jari - work on bootstrapping with IPsec for the time being, consider
4285 only if 3gpp wants that.

Petrescu - For dual stack, separate problem statement preferred for
mipv6 wg.

George - Have a common problem statement doc.

Hesham - Good to have a problem statement document, but not necessary
for the solution development.

Vijay - The problem description in the DS-MIPv6 solution document is
sufficient for DS-MIPv6. A separate problem statement is not needed.

Jari: Some adjustment to the charter needed. Will change charter
monthly if that's what we want


3. DHCP Option for Home Information Discovery in MIPv6
-------------------------------------------------------
I-D: I-D:  draft-jang-mip6-hiopt-00.txt

Hesham - has been discussed on the list, does it needs to be
standardised at all?

Petrescu - networks are identified by other means, not the proposed
HNid

Hesham - usage of HNid is common practice

Alper - This doc is next step after the framework doc.

Gerardo - Objects to a standalone document

Alper - this doc should be standalone. It can support static
configuration. Similar to how RFC 2132 defines a DHCP option for
MIPv4 home agent.

Vijay - There was never an intention to define a framework document,
just one solution document for the integrated scenario based on DHCP.

Hesham - lets take it to the mailing list.

Gerardo - has been discussed for more than 6 months. we need to
decide.

Vijay & Gerardo - Scrap the current working document if thats not
needed at all. draft-jang can define how to use DHCP for MIP6
bootstrapping.

Hesham - solution is agreeable, but no agreement on document
organization. Work offline and send something to the MIP6 mailing
list

4. Problem statement for Dual Stack MIP
---------------------------------------
I-D: draft-ietf-mip6-dsmip-problem-02.txt
No discussion

5. Dual Stack MIPv6
-------------------

I-D: draft-ietf-mip6-nemo-v4traversal-01.txt

Petrescu - why do we need keep-alive?

Hesham - to keep the NAT bindings alive

Petrescu - there are NATs which do not keep mappings even in
presence of keep alives

Henrik - questions the statement. does not believe there are NATs
like that.

Alex - have seen them

Henrik - we need product name and model number sent to the list
to verify Alex's statement

Hesham - scenario: dynamic detection of NAT in the HA's domain:
there might be IPRs

Vijay - nice to have, not necessary feature. Could be in a separate doc.

Hesham - should the feature be added or not?

Alex - The problem statement does not talk about this scenario.

George - not necessary in the DS-MIPv6 solution document

Henrik - IPR bothers him. if this will limit open source development
of this draft, then we can't have it

Leung - optional feature, it does not hurt having it

Vijay - It would be hard to distinguish which part of the spec has
IPR claims and which does not. IPR disclosure statements don't specify
that.

Sri: it does not make sense to not standardise it because of IPR. NEMO
standardised IPRed solutions.

Vijay - Each IPR decision needs to be taken separately. Precendent is
not useful.

Ruiji: relax 3775 for the NAT case (req to use altCoA when ESP is used).

Vijay: look at it as updating 3775 for NAT case

6. HA Reliability
------------------
I-D: draft-ietf-mip6-hareliability-00.txt

? - Don't think we can pre-establish multiple security associations as
specified

Ryuji - this is done at bootstrapping time

Petrescu - Why didn't we extend BRR instead of creating HA switch?

Brian - We could have, but didn't

Hesham - Why do we have switchover message?

Vijay - It's sent from the standby HA to become active

Bob Hinden - Should be very careful with deteting HA failures and
switching home agents. it is a hard problem. see VRRP for more details.

? - There are 2 things ? fault detection and state transfer ? fault
detection is not specific to this WG, they are IETF-wide so it would
be good to define them separately for that reason

Kent - routers already have hello beacons for a lot of things, we're
adding one more thing here. should we make this more generic and maybe
separate it out?

7. Experimental and Vendor-specific options and messages
---------------------------------------------------------

I-D: draft-devarapalli-mip6-vsm-00.txt
     draft-devarapalli-mip6-experimental-messages-00.txt

Alex - Why do we need both?

Vijay - Vendor-specific could be deployed, experimental shouldn't.
They are for separate purposes.

Henrik and Kent against vendor-specific message, ok with vendor
specific mobility option

8. Bootstrapping for RFC 4285
------------------------------
I-D: draft-devarapalli-mip6-authprotocol-bootstrap-00.txt

Hesham - Will this be informational like 4285?

Vijay - Yes

Vijay - What should the WG do?

? - Not currently in charter, if we do it it's informational, will
add it to the charter discussion

9. AAA goals status
-------------------
I-D: draft-ietf-mip6-aaa-ha-goals-02.txt

Gerardi - should we consider requirements for 4285 bootstrapping?
no comments

10. Scenario analysis and problem statement of the dual-stack mobile entity
roaming in the ipv4 and ipv6 network
--------------------------------------------------------------------------
I-D: draft-wan-mip6-nemo-dsanalysis-00.txt

George - need to explain the problems better

Henrik - doesn't see what the problem is either; believes dsmip will
solve this

Henrik- if the home network doesn't support ipv4, but you need to use
it, what do you do? Why can't you just deploy ipv4 there to solve it?
That is the simplest solution.  Same with ipv6.

Hesham - what are you going to do with this ipv4 address if the link
doesn't support it? Tunnel it somewhere?  DSMIPv6 solves this today.

Hesham - it's not clear all the scenarios are problems

George - need to better define the protocol and the scenario it will be
used in

11. MIPv6 Firewall issues
-------------------------
I-D: draft-bajko-mip6-rrtfw-00.txt

- Some work done in NSIS WG based on NSLP
- Gabor presented some slides on modifying return routability messages
to make Mobile IPv6 friendly to firewalls.

12. Next steps
---------------
 - revised charter
 - consider new wg docs based on charter


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