Subject: [Mip6] IETF68 WG meeting minutes

From: Basavaraj Patil <[email-masked]>
Date: Fri, 20 Apr 2007 15:59:45 -0500

Minutes of:
Mobility for IPv6 (mip6)
At: IETF68
March 19th, 2007

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

Credit for these minutes:

1. Ahmad Muhanna ([email-masked])

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

Chairs presented the agenda:

- Alper suggested to move the DHCP discussion after the bootstrapping
agenda item.

2. WG status and I-Ds update                5 Mins

- Raj presented the WG Status.
- Raj invited Jari to present his idea about merging the WGs MIP6,
  NEMO, and Monami6
  - Jari presented consolidating WGs MIP6, NEMOW, and Monami6 in one.
  - These WGs handle the same technology.
  - Jari gave a very brief status of what these WGs are doing.

- Raj presented the WG Document status.
  - Mip6-ikev2 draft is on the editor queue
  - Privacy location, Rajeev has addressed all security issues and
    concerns and it is in good shape to move forward.
  - Hesham mentioned that it is difficult to update the DSMIP draft
    without feedback from the group.

- New WG document
  - Mip6-rfc4285bis, the primary change is very small change to fix
   the key length. 

- Completed WG LC:
  - Why auth data option
  - AAA-Ha-goals
  - Bootstrapping integrated

- Ready for WG LC
  - Mip6-vsm
  - Experimental-messages
  - Nemo-v4traversal
  - Mip6-radius
  - Mip6-hareliability

Raj asked the group if anyone has any comments. No comments.

......................................

3. MIP6 support for DS hosts/routers - Open issues and discussion
   I-D: draft-ietf-mip6-nemo-v4traversal-03
   Hesham Soliman                    15 Mins

- It is an update to the existing draft
- Allows the MN to use either IPv4 or IPv6 CoA.
Keiichi: if we can specify the tunneling mechanism, currently we can
  use either IP-in-IPv6 or IP-in-IPv4. He proposed to specify the
  tunneling mechanism.
Sri: There is proper qualifier.
Hesham: do you agree that you can receive it and after that based on
the version you can do the switch.
Sri: agreed that should work. But generally a qualifier is needed when
do encapsulation. 
Kent: when looking at UDP header, in this case, there is a specific
UDP port to specify.
Alex: there will be one probably
Hesham: said that we have two cases
Alex: said when it is an IP-in-IP we do not need another header.
Kent: said is that specific to Mobile IP encapsulation? Why do not we
use a generic encapsulation mechanism?
Sri: said, if there is a fire wall, there is a problem.
Henrik: said that we heard this from Sri many times but this is not an
issue.
Francis: it was not designed for this purpose
Henrik: V4 mapped address was not designed for this purpose. The
 second bullet is kind of bogus. I am not implemented this and I have
 to rely on other people who implemented this.
Hesham, said Pascal implemented this and Keiichi did but he did not
comment on it. 
Henrik continued saying that should be stated more strongly.
Hesham: do you agree or disagree to bind the ..
Henrik: yes
Vijay: this is one sided of solving the issue. IPv4 CoA is carried
 in. you have to look into the most address and there was many issues
 raised to why it is a bad idea.

Kuntal: one more issue discussed on the ML. one proposal to allow
DHCPv6 to be used. I did not see any comment. Hesham and Raj asked
Kuntal to register the issue on the tracker.

Gopal: the chairs will send an email. Is that ok with you, asking Hesham.
Hesham said: Yes.
Is there any issue for using RF4334, I do not want to go and ask for
another port. 
Hesham has not thought about it.
Gopal, if it can work with two ports, then let us be.
Henrik: we can easily make it work with by having an intermediate
thing. There should not be a problem using RFC4334.
Hesham: they might benefit from other tunneling GRE and that stuff.
Henrik: it is even possible, we took some extra space from MIPv4
traversal, but it seems that a good idea.

Raj let us close this issue at this point. Let us discuss it and reach
consensus. 
Henrik: after hearing Vijay point and agree and change my point by
reserving a new port.
Raj: will post on the mailing list.

...................................

3a. UDP Encapsulation for IPv4 and IPv6 in DS-MIPv6
    Issue 93 in MIP6 tracker (http://www.mip4.org/issues/tracker/mip6/)
    Vijay Devarapalli                    15 Mins

Vijay presented UDP encapsulation for IPv4 and IPv6 in DS-MIPv6
Raj, we will limit the amount of time and we will be better off if we
think about them and make a decision later.
Henrik: for option 4: you are limited to always have one type of
encapsulated header.
Vijay: you can send a new BU.
Henrik: when I consider how the kernel handles incoming packets it
will be easier for the in buffer to handle incoming code. I do not
feel very happy about this one.
Alex: Pascal if you set a flag in BU but what if you want to send IPv6
traffic in the middle. Is it possible to have this without NAT UDP.
Alex, I do not know how you can have IP-in-IP over UDP.
Kent:  No. 3 other than using an over head I think it is ok.
Gopal, Vijay did a good job presenting these options, let us
discussing them on the mailing list.

.......................................

5. Home agent reliability
   I-D: draft-ietf-mip6-hareliability-01.txt
   Ryuji Wakikawa                    15 Mins

Ryuji presented Home Agent Reliability Protocol.

- Issue about the convergence time in case of an HA switch. Sri
  mentioned that this is not an MN issue.

Raj: please review the document and send feedback.

............................

6. Discussion of open issues on I-Ds that are in WG LC    20 Mins
   a. draft-ietf-mip6-bootstrapping-integrated-02.txt

Kuntal presented the integrated AAA-HA solution.

Kilian said that he did not proposed what the slide says. In other
words, he said the draft should not mention that.
Vidya: I am fine with mentioning that about the DHCP security. I had
some comments that I sent on the list which talk about physical
security. There is nothing about DHCP security.
Jari: what DHCP security? Having said that, if Vidya is frightened
what you are suggesting is just fine or some ll security mechanism.
Hesham: it is public knowledge, the IP address.
Vidya: the text seems like it is mandating something
Alper: it is a mistake to address DHCP security and we should remove it.
Kuntal: we will remove this comment and issue is closed.
John Michael: the key authenticate the DHCP server and DHCP
client. Where the key comes from.
Kuntal, Alper, Vidya, Raj there is no sensitivity in the information
carried. Move on. 
Vidya: we do not need to mandate anything just as clarification.
Kuntal agreed.
Vidya: this is not closed. Do we need to discuss here or on ML?
Kuntal: I have some solution.
Raj: take the comments to the ML.
Kilian: this scenario is not considered.
Raj let us discuss offline.
Alper: local HA issue is not specific to this draft and we should not
tie it to this draft.
Vijay: this issue is a little different RFC3403. if the MN got a DHCP
address aside from IKEv2, I am not sure how this will be addressed.
Kuntal: we get the address from NAS and it is stateless.
Vijay: DHCP is used as a tool.
Kuntal: yes as a tool to get an address. This is an address and can be
used. 
Vijay: is there a problem. What is the relationship between the DHCP
server and HA. For HA it is not an issue but for HoA it is.
RAJ: let us take the issue to the ML.
Kuntal: prefix also may have the same issue.
Vijay: there is another DHCP option draft, can we move forward and
address that in that draft.
Kuntal: will update the current draft and then post emails about the
open issues. 
Vijay: this document has a section how the MN should send DHCP request
and how the DHCP relay should work. Also that other document also has
the same text. It should be addressed in one draft but not in both.
Vijay will send the text to the authors.

.......................................

4. DHCP Option for Home Information Discovery in MIPv6
   I-D: draft-ietf-mip6-hiopt-02.txt
   Heejin Jang                        10 Mins

Vidya: more HL Q, if we assigned HA this way, if we use IKEv2 to fetch
the information why we need DHCP?
Vidya: why
Gerardo: I agree with Vidya that we do not need this document. It
seems that as if it is a companion document but not needed.
Raj: do we need additional information.
Kuntal: there was discussion in WiMAX and they added this option.
Raj: then you need to put forward a Use case and if it is specific to
some SDOs then we can rethink it.
Raj: do we need that info
Raj: write the use case and why we need this option.
Bechet: we need the address but do we need stateless or not.
Raj, Alper let us take it to the ML.
Alper: what is the process, we have open issues? Can you guys send
your comments ASAP that we can address them
Vijay: both these documents have similar changes, can we write another
document. 
Raj: we do not need another one.

........................................

Non-WG items:

1. Service Selection for Mobile IPv6
   I-D: draft-korhonen-mip6-service-00.txt
   Jouni Korhonen                10 Mins

Henrik: Mostly concern about the ID if it is plain that is ok but it
has to be much more secure.
Jouni: will be sent in BU
Henrik: If this ID is handed out by the provider, it should not be
possible to change it.

..............................

2. Mobility Header Signaling Message
   I-D: draft-haley-mip6-mh-signaling-02.txt
   Sri Gundavelli                10 Mins

Alper; what is the scope of the message.
Sri: Opaque load, HA is going down after 1 hr or something?
Alper: is that related to MIPv6 related or prepaid.
Henrik: there is a similar thing in MIPv4. My worries when saying
opaque. This becomes not MIP6 specific.
Alex: looks like a good idea.
Hesham: there is another draft about vendor specific because there is
another draft which is VS draft.

It was agreed that this is a good thing for MIP6 and Raj will ask for
consensus to make this a WG document.

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