[11:43:25] --- ruri_hiromi@chat.gizmoproject.com has joined
[11:43:40] --- ruri_hiromi@chat.gizmoproject.com has left
[11:44:23] --- behcet.sarikaya has joined
[11:54:21] --- ruri_hiromi@chat.gizmoproject.com has joined
[11:56:28] --- TJ has joined
[12:00:14] --- apetrescu has joined
[12:02:14] <apetrescu> slides are at https://datatracker.ietf.org/meeting/70/materials.html#wg-mext
[12:02:16] --- Will Ivancic has joined
[12:02:56] <TJ> (Agenda bashing)
[12:02:56] --- ruri_hiromi@chat.gizmoproject.com has left: Replaced by new connection
[12:03:04] <apetrescu> slide: Deliverable Status
[12:03:06] <TJ> That's a long agenda...
[12:03:21] <apetrescu> slide: Deliverables (I)
[12:03:53] --- ruri_hiromi@chat.gizmoproject.com has joined
[12:04:05] --- jhlim has joined
[12:04:14] <apetrescu> Jari Arkko speaking
[12:04:20] <apetrescu> JA: ready for permission to go something
[12:04:26] <apetrescu> JA: no need to anything today
[12:04:30] <apetrescu> JA: waiting for revision
[12:04:34] <apetrescu> Raj Patil is RP
[12:04:37] <apetrescu> RP: referring to...
[12:04:51] <apetrescu> RP: comments following IESG review, authors and myself wait to revise draft based on comments
[12:04:57] <apetrescu> RP: restructuring the doc
[12:05:02] <apetrescu> RP: tnx very much for that
[12:05:03] <TJ> Referring to the draft-ietf-mip6-whyauthdataoption
[12:05:44] <apetrescu> slide: Deliverables (II)
[12:06:02] --- rjaksa has joined
[12:06:36] <apetrescu> slide": Deliverables (II)
[12:06:59] <apetrescu> slide: Deliverables (III)
[12:07:14] <apetrescu> Will Ivancic is WI
[12:07:22] <TJ> Marcelo asking about the Automobile-related draft
[12:07:25] <apetrescu> WI: turn on into a mext draft, much pretty unchancged
[12:07:26] <TJ> if any of the authors are here.
[12:07:42] <TJ> (none of them are here to talk about plans)
[12:07:44] <TJ> will ask on mailing list
[12:08:39] <apetrescu> slide: Deliverables (IV)
[12:08:42] --- intvelt has joined
[12:09:26] --- teco has joined
[12:09:31] <apetrescu> HAnnes Tschoefenig HT approaching mic
[12:09:46] <apetrescu> HT: comment on mip6 radius stuff
[12:10:09] <apetrescu> HT: it wasn't progerss in the last few months because we wanted to do dime bootstrapping, once that done then basically align it with radius work
[12:10:13] <apetrescu> HT: get it aligned
[12:10:21] <apetrescu> Marcel Bagnulo is MB
[12:10:26] <apetrescu> MB: already aligned?
[12:10:35] <apetrescu> HT: we started workign with two docs, update that document
[12:10:39] <apetrescu> MB: ok thanks
[12:11:04] <apetrescu> slide: Deliverables (V)
[12:11:39] <apetrescu> slide: Deliverables (VI)
[12:13:06] <apetrescu> Ryuji Wakikawa is RW approaching
[12:13:27] <apetrescu> RW: about HA reliability protocol, have been working on this 1 1/2 year, document is almost ready
[12:13:34] <apetrescu> RW: not any reason to wait more than a year.
[12:13:58] <apetrescu> MB: agree we don't have to wait just because the charter says so, just that we try to get more comments, in order to do that we need to do LC WG LC
[12:14:07] --- john.zhao has joined
[12:14:09] <apetrescu> RP: there was also generic notification draft
[12:14:15] <apetrescu> RP: accepted as WG doc it was.
[12:14:23] <apetrescu> RP: any reason why it's not hear?
[12:14:26] <apetrescu> MB: not in our charter
[12:14:32] <apetrescu> MB: not are we chartered to do that work
[12:14:41] <apetrescu> RP: dsmipv6 and all these things
[12:14:51] <apetrescu> RP: generic notification already part of MIP6 charter and deliverables
[12:14:56] <apetrescu> MB: I don't know you tell me
[12:15:07] <apetrescu> RP: charter was approved
[12:15:13] --- rdenisc has joined
[12:15:25] <apetrescu> JA: if we missed that in the charter text then we put it back in the recharter, let's discuss it
[12:15:51] --- washad has joined
[12:16:10] <apetrescu> Jonah Pezeski approaching mike is JP
[12:16:19] <apetrescu> Pezeshki is that I think
[12:16:23] --- fdupont has joined
[12:16:24] <apetrescu> JP: quick q of deliverables
[12:16:37] <apetrescu> JP: updating rfc3775? what impact if on rfc3776?
[12:16:54] <apetrescu> MB: still not clear what the update will contain, idea is minor modifications.
[12:17:01] <apetrescu> JP: not in that much depth then?
[12:17:04] <apetrescu> JP: tnx
[12:17:07] <apetrescu> Vijay Devarapalli
[12:17:26] <apetrescu> VD: 3776 doesn't ... that, if we update 3775 we can refer to ikev2 as and not ikev1.
[12:17:38] <apetrescu> VD: so this update doesn't revise 3776
[12:18:55] <apetrescu> Hesham SOliman presenting DSMIPv6 Update slides at http://www3.ietf.org/proceedings/07dec/slides/mext-0.ppt
[12:18:59] <apetrescu> slide: Status
[12:19:56] <apetrescu> slide: Comments on the Scurity considerations section
[12:20:46] <apetrescu> HT approaching mic
[12:21:17] <apetrescu> HT: on the previous slide you had assumption UDP calculation is never used in ipv6? IS this a good assumption, not sure... firewalls, stateful back filters
[12:21:28] <apetrescu> HS: we no have solution, if that becomes a somulotuuin.
[12:21:39] <apetrescu> HT: what happens to your document if above it you use udp encapsulation?
[12:21:51] <apetrescu> HS: may need some changes, but point is we don't see udp in ipv6 networks, why?
[12:21:59] <apetrescu> HT: because that's way stateful packet filtering works
[12:22:01] <apetrescu> HS: rfc?
[12:22:02] <apetrescu> HT: no
[12:22:10] <apetrescu> HS: when there's one then .
[12:22:19] <apetrescu> HT: when design protocol, already some stuff smells like problems
[12:22:22] <apetrescu> HS: no
[12:22:26] <apetrescu> HT: firewalls work today
[12:22:35] <apetrescu> HS: you assume an RFC with encapsulation firewall
[12:22:38] <apetrescu> HS: but not know
[12:22:46] <apetrescu> HS: other solutions for fw traversal, why this?
[12:22:52] <apetrescu> HT: this smells like problem but go ahead.
[12:23:53] --- xiaohunhun has joined
[12:24:07] <apetrescu> slide: Next steps
[12:25:40] <apetrescu> George Tsirtsis is GT
[12:25:53] <apetrescu> GT: I think it's still not clear to me exactly what this means
[12:26:05] --- sureshk has joined
[12:26:11] <apetrescu> GT: Karen may have a point, but not clear to me the right way to approach the problem is to change something in the spec? other config stuff?
[12:26:26] <apetrescu> GT: talked to Karen a bit offline, maybe the good thing is to write it down in a draft, see what is
[12:26:32] <apetrescu> GT: then maybe deal with it after this is done
[12:26:36] <apetrescu> HS: only have one week
[12:26:44] <apetrescu> HS: either that or we agree this is not for now
[12:26:59] <apetrescu> VD: same comment as GT, this got a problem in the draft, try to see how to solve this issue
[12:27:04] <apetrescu> KAren Nielsen is KN
[12:27:28] <apetrescu> KN: fine with the solution, with the division put in the base draft, also think it would be gfood to be considered afterwards, whether a solution to support or something else.
[12:27:39] <apetrescu> HS: never thought the same, but IU really think we're done
[12:27:44] <apetrescu> RP: HS why the q mark?
[12:27:52] <apetrescu> HS: myself wasnt sure, another quick.
[12:27:58] <apetrescu> HS: another 1 week last call,
[12:28:27] <apetrescu> Suresh Krishnan is SK going to present
[12:28:49] <apetrescu> slides don't seem to be available
[12:29:08] --- florent.parent@gmail.com has joined
[12:29:14] <apetrescu> slide: MIP6 Firewall DT update
[12:29:59] <apetrescu> slide: Recommendations for configuring firewalls
[12:30:06] --- intvelt has left
[12:30:26] <apetrescu> slide: Related activity
[12:31:01] <apetrescu> slide: Proposed way forward
[12:31:33] --- Gerardo has joined
[12:31:45] <apetrescu> slide: Guidelines for Firewall Administrators Moile IPv6
[12:31:57] <apetrescu> GT: the two drafts are to be done what? submissiuon WG?
[12:32:08] <apetrescu> SK: as input from DT, but after this as inputs as wg drafts
[12:32:19] <apetrescu> SK: mip6 fw not in charter, didn't know the scope
[12:32:30] <apetrescu> SK: we caught from implementers, fw vendors, researchers
[12:32:34] <apetrescu> SK: features oriented
[12:32:37] --- intvelt has joined
[12:32:44] <apetrescu> GT: the two docs you agreed are proposed to become WG docs?
[12:32:46] <apetrescu> SK: yes
[12:32:55] <apetrescu> GT: did you attend the SAFE bof?
[12:33:02] <apetrescu> SK: not relates?
[12:33:05] <apetrescu> GT: not relates
[12:33:13] <apetrescu> HT: different approach
[12:33:20] <apetrescu> HT: 3 different approaches you can do
[12:33:24] <apetrescu> HT: middlebox work
[12:33:35] <apetrescu> HT: 1 approach you assume you can solve by configuring box correctly. ok.
[12:33:40] <apetrescu> HT: if believe in that then simple do.
[12:33:51] <apetrescu> HT: other approach ICE, STUN, TURN type of approach.
[12:34:01] <apetrescu> HT: 3rd approach you talk to these boxes implicitely or explicitely
[12:34:09] <apetrescu> HT: ... would fall into that category.
[12:34:27] <apetrescu> JA: the 3rd category of ... that's not something this WG should be working on.
[12:34:32] <apetrescu> SK: applicable to more than MIP6
[12:34:38] <apetrescu> JA: other efforts in ietf deals that
[12:34:57] <apetrescu> HT: one of the docs during SAFE bof eysterday actually shows certain different protocols could use to contact fw and talk to
[12:35:19] <apetrescu> GT: I'm asking, SAFE is ..., but to me, if that work goes ahead it can be huge, by things like this, mip6, nat...
[12:35:23] <apetrescu> GT: look at that this way
[12:35:31] <apetrescu> SK: these two drafts are something we can do today
[12:35:41] <apetrescu> SK: give admins recommendations
[12:35:46] <apetrescu> SK: RO, bidirecitonl traffic
[12:35:49] <apetrescu> Sri Gundavelli
[12:35:57] --- Gerardo has left
[12:36:01] <apetrescu> SG: you said talking, for different audience, functional is so interrelated
[12:36:05] <apetrescu> SK: q many people had
[12:36:11] <apetrescu> SK: admins draft is a leap of faith...
[12:36:16] <apetrescu> SK: unsolicited messages
[12:36:34] <apetrescu> SK: vendor draft is actually scientific (HoTI coming in? let the HoT back) much more rational
[12:36:40] <apetrescu> SK: two totally different audiences
[12:36:43] <apetrescu> SK: firewall vendor.
[12:36:51] <apetrescu> SK: combined draft it as before, then we split it
[12:37:07] <apetrescu> SG: this WG is not targetted to ..ining aspects, HA aspects is targetted, nothing new.
[12:37:13] <apetrescu> SK: correct, but this is just a guideline.
[12:37:24] <apetrescu> SK: now people don't even know, MIP6 packet format is not obvious.
[12:37:32] <apetrescu> SK: whether.... not obvious at all.
[12:37:39] <apetrescu> SK: need to give some kind of recommendation.
[12:37:54] <apetrescu> HS: responding to GT, out of the 3 categories mentioned, this is one only for MIP6.
[12:38:04] <apetrescu> HT: mentioned this can be deployed, other things can;t/
[12:38:15] <apetrescu> HT: true, also true for many other things, its' not the oend of things.
[12:38:35] <apetrescu> HT: but the incentive for end devices, guys who run NATs, small coffee place. HAsn't there been too many incentives.
[12:38:48] <apetrescu> HT: mayny cases it is not an issue, it is an incentive business model.
[12:39:02] <apetrescu> SK: not sure what direction to go we were through, lot of protocols there are.
[12:39:10] <apetrescu> SK: even in IETF, what is the best one?
[12:39:16] <apetrescu> SK: not anything technically wrong
[12:39:33] <apetrescu> HT: ICE is different, deosn't talk to. If there's a path between two nodes that work then it will find it.
[12:39:58] <apetrescu> slide: Introduction
[12:40:59] <apetrescu> slide: Classification of recommendations
[12:41:06] <apetrescu> slide: Security
[12:42:13] <apetrescu> slide: Further steps
[12:42:35] <apetrescu> slide: vendor recommendations
[12:42:39] <apetrescu> slide: Introduction
[12:43:54] <apetrescu> slide: Assumptions
[12:44:24] <apetrescu> slide: Classification of recommendations
[12:44:29] <apetrescu> Behcet Sarikaya is BS
[12:44:36] <apetrescu> BS: you mentioned some messages seem to be...
[12:44:44] <apetrescu> BS: mentioned on MIP6 but what about PMIP6?
[12:44:50] <apetrescu> BS: we also talk RO for PMIPv6?
[12:45:05] <apetrescu> SK: this was chartered before any of that happened, maybe then make go back, not in scope now
[12:45:11] <apetrescu> SK: if they tell us to do it we'll do
[12:45:20] <apetrescu> HS: no need to know the mssage type, you just need the ...
[12:45:31] <apetrescu> SK: look at message type for HoTI then pinhole opens
[12:45:34] <apetrescu> SK: ...
[12:45:49] <apetrescu> HS: you assuming MIP6 is endtoend secure, then you'd rely on provided...
[12:45:55] <apetrescu> HS: you'd choose to let it through.
[12:46:03] <apetrescu> HS: other message types are defnined.
[12:46:09] <apetrescu> HS: need to understand sequence.
[12:46:13] <apetrescu> SK: trickier problem
[12:46:19] <apetrescu> SK: not know how to keep this up to dya.
[12:46:29] <apetrescu> SK: if you give a black check
[12:46:36] <apetrescu> SK: super insecure mobility protocol
[12:46:44] <apetrescu> SK: somebody Mobility HEader, someone
[12:46:47] <apetrescu> SK: not know the answer
[12:46:53] <apetrescu> HS: could do that wiht message type
[12:46:57] <apetrescu> HS: two cooeprating nodes
[12:47:06] <apetrescu> HS: cant put anything else on top of mobility header
[12:47:16] <apetrescu> HS: can't put a UDP packet on top of mH
[12:47:24] <apetrescu> sorry last two were SK not HS
[12:47:33] <apetrescu> SG: look at PMIP6, did you look at flags
[12:47:42] <apetrescu> SK: rihtnght now not specified
[12:47:48] <apetrescu> SK: if in scope we can add that in.
[12:47:57] <apetrescu> SG: if you not look at that then what does it mean?
[12:48:05] <apetrescu> SK: closer to mike please
[12:48:26] <apetrescu> SK: not anything specific for pmip, because I thought it was not in the scope of hthis activity.
[12:48:30] <apetrescu> slide: Further steps
[12:48:40] --- Will Ivancic has left: Computer went to sleep
[12:48:56] <apetrescu> WI: in the scenario with both drafts, HA behind a fw, is there anything about the CN initiating the conversation to the MN
[12:49:06] <apetrescu> SK: the CN what you need to dois you need to figure out.
[12:49:13] <apetrescu> SK: decision is to open a pinhole
[12:49:19] <apetrescu> SK: we have a rule
[12:49:28] <apetrescu> SK: if have a mobile then go and open up a port
[12:49:31] <apetrescu> WI: ok tnx
[12:50:25] --- Will Ivancic has joined
[12:50:39] <TJ> AP: You are saying this is necessary (this firewall work and recommendations) because MIPv6 messages are not obvious/easy to understand. And this is a recommendation to a firewall administrator to explain what MIPv6 is like, and it's going to be better than what the MIPv6 message descriptions are?
[12:51:19] <TJ> SK: That's the vendor draft. It explains that if you want to let RO traffic through, these are the messages you let through, and these are the pinholes you must open up.
[12:51:48] <TJ> AP: We want to let everything through.
[12:52:09] <TJ> SK: But the administrators don't. We are just explaining how to identify MIPv6 traffic, and if you want to let it through, this is how you let it through.
[12:52:27] <TJ> SK: We are not taking any moral stance on whether you should let things through.
[12:52:57] <TJ> AP: So some parts of MIPv6 are going to be let through and others are not? I don't agree with that.
[12:54:20] <apetrescu> SK and MB talking
[12:54:33] <apetrescu> MB: what people think it is the right way for firewall traversal
[12:54:46] <apetrescu> HS: IMHO, for MIP6 the whole thing is about edicating people about
[12:54:54] <apetrescu> HS: scenarios
[12:55:01] <apetrescu> HS: this is good enough people
[12:55:04] <apetrescu> HS: other approaches
[12:55:13] <apetrescu> HS: traversing fwals
[12:55:27] <apetrescu> HS: for this narrow arpproach it's enough to tell people just configure the firewall
[12:55:49] <apetrescu> RP: what to do, the previous mip6 charter said we need to work on issues respect to firewalls deployment
[12:56:02] <apetrescu> RP: enables for deployment. From that prespective, it made sense
[12:56:30] <apetrescu> MB: assuming this is the approach we want to follow, anybody wants to?
[12:56:36] <apetrescu> MB: thanks
[12:56:45] <apetrescu> MB: premature, only two people have read.
[12:56:52] <apetrescu> MB: please people read the document.
[12:57:04] <apetrescu> MB: informed decision we must take if you read it.
[12:57:20] --- jhlim has left
[12:57:47] <apetrescu> Lin Benjamin is BL is going to present
[12:57:53] <apetrescu> slide: Verification of Care-of Addresses...
[12:58:03] <apetrescu> slides at http://www3.ietf.org/proceedings/07dec/slides/mext-1.pdf
[12:58:07] <apetrescu> slide: Contents
[12:58:33] <apetrescu> slide: Problem
[12:59:23] <apetrescu> slide: MIP6 vs Monami6
[13:01:35] <apetrescu> TJ Kniveton approaching mic
[13:02:59] <apetrescu> TJ: if you have a malicious entity that compromises the MN, why would it go through the trouble having a HA doing an attack on its behalf?
[13:03:32] <apetrescu> TJ: not sure this is some sort of amplification attack? To me it's just a case of cormpropmising another machine, same sort of attack from a MN what you can do from a HA with multiplke bindings.
[13:03:35] <apetrescu> SK: I can answeer
[13:03:48] <apetrescu> SK: you can talk to CNs, sends bindings to hundreds of victims
[13:03:55] <apetrescu> SK: no need of a high bwidth link to do ti
[13:04:09] <apetrescu> SK: in this case you can like use the bw of all CNs you have, attack more than one at same time
[13:04:16] <apetrescu> SK: set like thousand of vicitms
[13:04:22] <apetrescu> SK: then you could just go away
[13:04:33] <apetrescu> TJ: difference between MN links and HA's link
[13:04:57] <apetrescu> HS: you only assuming that attacker takes over the MN, not assuming that has a valid security credentials but doing wrong thing
[13:05:03] <apetrescu> HS: can't do much about it, jus track it.
[13:05:14] <apetrescu> BL :reason is that id of MN is spoofed by attacker
[13:05:16] <apetrescu> HS: ok
[13:05:24] <apetrescu> HS: I think there are ways similar ways handling of CN
[13:05:37] <apetrescu> HS: but if th eMN is doing the wrong thing then you can't do anything about that
[13:05:50] <apetrescu> GT: I raised that point on the mailing list, of course a legiitimate mmobile.
[13:06:00] <apetrescu> GT: you can not prevent the attack, but you can cut the attackers
[13:06:01] <apetrescu> HS: true
[13:06:27] <apetrescu> slide: Solution Approaches
[13:08:36] <apetrescu> slide: Considerations/Next Steps
[13:09:14] <apetrescu> MB: what's the oppinoon of the WG is this thread good enough?
[13:09:19] <apetrescu> MB: should we care about this?
[13:09:31] <apetrescu> SK: it is relevant, 3rd party bombing attack is very relevant
[13:09:42] <apetrescu> GT: looking at aspecific solution? dont know but problem I agree
[13:09:51] <apetrescu> VD: not convinced that you can't prevent this very simply
[13:09:59] <apetrescu> VD: HA can prevent how many HoAs can bind
[13:10:05] <apetrescu> GT: that's not solution
[13:10:10] <apetrescu> BL: that's a solution
[13:10:22] <apetrescu> VD: this solution doesn't need a WG item, no need a policy, just
[13:10:26] <apetrescu> VD: charter of mext
[13:10:40] <apetrescu> MB: this is a comment on multiple CoA draft, threat there is, can we do somehting.
[13:10:41] <apetrescu> VD:.
[13:10:48] <apetrescu> MB: you think ...? threat is ok?
[13:10:57] <apetrescu> SK: threat is real
[13:11:06] <apetrescu> SK: CoT in MIP6 we have because the threat exists
[13:11:11] <apetrescu> VD: not, CN
[13:11:15] <apetrescu> KN: no
[13:11:20] <apetrescu> MB: out of time
[13:11:27] --- washad has left
[13:12:02] <apetrescu> Ryuji Wakikawa is RW is going to present slides not available
[13:12:09] <apetrescu> slide: Updates from -03
[13:12:35] <apetrescu> slide: Alternate CoA option
[13:13:50] <apetrescu> slide: Status Code
[13:14:38] --- john.zhao has left: Replaced by new connection
[13:14:42] --- john.zhao has joined
[13:14:58] <apetrescu> slide: DSMIPv6
[13:16:13] <TJ> AP: Why are you adding a new feature?
[13:16:17] <TJ> RW: It's not a new feature.
[13:16:25] <TJ> AP: I disagree with the comment (George's comment).
[13:16:30] <apetrescu> GT: consider timing
[13:16:51] <apetrescu> GT: DSMIPv6 is getting adopted in several places, it will be deployed, this is federal in of mahny people
[13:16:57] <apetrescu> GT: no customer waiting this
[13:18:08] <TJ> AP: It seems like a good exercise. We will do it because we can.
[13:18:20] <TJ> AP: Isn't this rescoping the draft?
[13:18:23] <TJ> RW: No
[13:18:31] --- hartmans@jis.mit.edu/owl has joined
[13:18:42] <apetrescu> GT: no reason not take into slide: Bulk Resitration for CN
[13:19:03] --- cabo has joined
[13:19:04] <apetrescu> sorry, the above line should be split after "into"
[13:19:25] <apetrescu> slide: RR with Bulk Resgitration (slide used in IETF65)
[13:20:03] <apetrescu> RW: should we go back to cnsonseusns?
[13:20:21] <apetrescu> GT: unlike ht eprevious comment, this one I'm not so convinced is necessary. I didn't know the bakground;.
[13:20:25] <apetrescu> GT: looked strange
[13:20:31] <apetrescu> GT: couldnt understand why
[13:20:59] <apetrescu> slide: Simultaneously home and Foreign attachments (The slide used in IETF65)
[13:22:14] <apetrescu> slide: H flag for BID sub-option (Slide used in IETF69)
[13:24:36] <apetrescu> slide: Comments from Keigo (slide used in IETF67)
[13:25:32] <apetrescu> slide: Operational Solution for returning home (Slide used in IETF67)
[13:26:35] <apetrescu> Ahmad Muhanna approaching mic
[13:26:52] <apetrescu> AM: missing something? My understanding of MIP6, MN attach to HA would deregister
[13:26:55] <apetrescu> RW: yes
[13:27:00] --- john.zhao has left
[13:27:12] <apetrescu> AM: you now say while attached to home link HA maintains a BC entry, right? is it deviation?
[13:27:35] <apetrescu> AM: multiple CoA registration, while doing that why are we handling the MN attached directly to HA as it looks as a foreign link?
[13:27:40] <apetrescu> RW: no intention change 3775
[13:27:47] <apetrescu> RW: point is HA knows that...
[13:27:47] --- john.zhao has joined
[13:27:52] <apetrescu> AM: HA registration anyways
[13:28:01] <apetrescu> RW: HA doesn't have any state for MN
[13:28:09] <apetrescu> AM: moving from foreign to home it did have before
[13:28:14] <apetrescu> AM: but if we say ...
[13:28:20] <apetrescu> AM: no need for deregistration
[13:28:40] --- john.zhao has left
[13:28:40] <apetrescu> RW: right, I mean, when the MN has multiple interfaces, HA has to decide which traffic goes to interface attached to home or to foreign?
[13:28:46] <apetrescu> RW: HA has to know whether ...
[13:28:54] <apetrescu> RW: but if it delays all binding info then no idea it has
[13:29:13] <apetrescu> AM: my suggestion is to limit this to my understranding of the draft saying multiple CoA, limit it to that?
[13:29:25] <apetrescu> AM: multihoming with a combination with hom elink and ofreogin link extend later
[13:29:30] <apetrescu> RW: you say later right?
[13:29:39] <apetrescu> AM: right, currently multiple CoA registraiton is...
[13:29:43] <apetrescu> AM: other comment I hae
[13:29:56] <apetrescu> AM: you say that the HA can always send 0 as successful, for Binding ID...
[13:30:09] <apetrescu> AM: I wouldn't suggest that, if there's any BID failure, that will enhance the process of the mn
[13:30:19] <apetrescu> AM: MN not successfull but still have to go through these chekcs
[13:30:28] <apetrescu> AM: any of those non successfull, then assign a new code
[13:30:32] <apetrescu> RW: check the status flag
[13:30:41] <apetrescu> SK: I think it's a valid scenario, but we try to be too smart here
[13:30:44] <apetrescu> SK: there's only two
[13:30:52] <apetrescu> SK: HA does proxy ND, other one is you don't
[13:30:59] <apetrescu> SK: these are the two home link solutions
[13:31:06] <apetrescu> SK: these are the two things we want to say
[13:31:07] <apetrescu> SK: done
[13:31:16] <apetrescu> SK: only two solutions are there
[13:31:20] <apetrescu> RW: that comment VD also made
[13:31:26] <apetrescu> RW: MN just doesn't.
[13:31:34] <apetrescu> MB: SK should we support this scenario ?
[13:31:38] <apetrescu> SK: not explore too much
[13:31:46] <apetrescu> RW: this case HA interpcepts the traffic
[13:31:51] <apetrescu> RW: one considers that...
[13:32:16] <apetrescu> RW: home link to the MN, MN has to run a layer2 address to the HA, because MN cant defend its HoA, this is like specifying MIP registration
[13:32:25] <apetrescu> RW: not an of implementing layer2 address.
[13:32:31] <apetrescu> RW: that's only concern
[13:32:50] <apetrescu> RW: for any traffic from MN from the intefrface attaached to home, not using NDP, construct other packet
[13:32:52] <apetrescu> RW: trickky part this is
[13:33:08] <apetrescu> RW: easy to mention in the document, easy to describe, but imlementation part getting hard
[13:33:19] <apetrescu> SK: there's something you assume here the home prefix is actually on a link
[13:33:27] <apetrescu> SK: we can avoid that with proper deployment
[13:33:29] <apetrescu> RW: right
[13:33:34] <apetrescu> Gerardo Giaretta is GG
[13:33:47] <apetrescu> GG: this is a ... scenario to enable, don't think we need to wait for that
[13:33:56] <apetrescu> GG: ready should we be for picking up a solution for that
[13:34:07] <apetrescu> GG: there's a n actual real home link, often the mobile node would be .
[13:34:19] <apetrescu> GG: would be much easier to be multihomed to home link than to foreign link
[13:34:41] <apetrescu> GG: multiple interfaces in that case you're always in the home link with one interface and on the foreign link with the other iface
[13:34:47] <apetrescu> speaker JApanese looks
[13:35:01] <behcet.sarikaya> keigo aso
[13:35:02] <apetrescu> speaker: provide mechanism for MN should/can be used for any connection
[13:35:21] <apetrescu> KA: not prefer the NDP solution, I prefer the ... mechanism (home - core) usage
[13:35:38] <apetrescu> SK: MN using some... EUI64, not trivial to create a.
[13:35:46] <apetrescu> SK: how easy is to create
[13:36:01] <apetrescu> SG: not sure to be in the document, because how would the policy be?
[13:36:11] <apetrescu> SK: my policy says that some flows on this link...
[13:36:13] <apetrescu> MB: running out of time
[13:36:22] <apetrescu> SK: sold that completely or don't do it at this point
[13:36:29] <apetrescu> slide: Comments from Vijay
[13:37:34] <apetrescu> MB: seems no consensuns here now at least
[13:37:36] <apetrescu> RW: yeah
[13:37:40] <apetrescu> MB: in general four items
[13:37:53] <apetrescu> MB: AFAIU if there's threat it seems should be
[13:38:04] <apetrescu> RW: we should say somehtin goint the Security Considerations section
[13:38:20] <apetrescu> MB: seems consensus for DSMIPv6, for threat, but no consensus what to do next
[13:38:29] <apetrescu> VD: simultaneous attachment on home link and foreign link
[13:38:42] <apetrescu> VD: numerous mails on list, but we don't have consensus on the solution
[13:38:51] <apetrescu> RW: many people said this is important
[13:38:56] <apetrescu> MB: I'll review mailing list
[13:39:51] <apetrescu> TJ Kniveton going to present on Prefix Delegation Protocol Selection slides not available
[13:39:57] <apetrescu> MB: TJ take your time not fast
[13:40:11] <apetrescu> slide: Presentation Outline
[13:40:34] <apetrescu> slide: Problem Statement and Overview
[13:41:30] <apetrescu> slide: NEMO Drafts: DHCPv6-based Prefix Del. (1)
[13:42:44] <apetrescu> slide: NEMO Drafts: DHCPv6-based prefix Del. (2)
[13:43:30] <apetrescu> slide: NEMO Drafts: NEMOM-based Prefix Del. (1)
[13:45:48] --- Will Ivancic has left: Computer went to sleep
[13:46:35] --- rdenisc has left
[13:46:39] <apetrescu> slide: NEMO Drafts: NEMO-based Prefix Del. (2)
[13:48:14] <apetrescu> slide: Other Reference Documents
[13:49:05] <apetrescu> slide: Working Group Discussion and Conclusions
[13:49:43] <apetrescu> Francis Dupont lining up
[13:49:46] <apetrescu> is FD
[13:50:06] <apetrescu> slide: MEXT Charter Items
[13:50:27] <apetrescu> slide: Questions
[13:51:43] <apetrescu> MB:as I mentioned before, we chartered do solution, 1 solution, not only because we're chartered, but becasue it makes sense
[13:51:50] <apetrescu> MB: how to proceed?
[13:51:59] <apetrescu> MB: which approach makes sense? why? convince us all
[13:52:10] <apetrescu> FD:confess I have to, not happy with two solutions
[13:52:36] <apetrescu> FD: you should use DHCPv6 as the only std way to provide prefix delegation, but we had problems for NEMO, I have an idea solving almost all problems, get good security
[13:52:46] <apetrescu> FD: real security, because DHCPv6 security not as good as
[13:52:49] <apetrescu> FD: AAA
[13:53:00] <apetrescu> FD: simple, put a DHCPv6 Relay on the Mobile Router
[13:53:14] <apetrescu> FD: so you can use addresses you want, no more link-local things, also complexity of DHCPv6.
[13:53:20] <apetrescu> FD: one part is lookall
[13:53:32] <apetrescu> FD: the other part is the chain of relays wchich can get, unicast multicast
[13:53:44] <apetrescu> FD: put a Client colocated on the Relay, the Relay talks those aprat
[13:53:57] <apetrescu> TJ: I'd like to hear moer abotu this, put in written format, draft, or idea is.
[13:54:00] <apetrescu> TJ: q back to you
[13:54:07] <apetrescu> TJ: start with assusmption using DHCPV6, why?
[13:54:14] <apetrescu> FD: I prefer to have one mehcnaisms
[13:54:23] <apetrescu> FD: long discussion on the IPv6 WG about how to do prefix delegation
[13:54:41] <apetrescu> FD: first suggest to use DHCPv6, then alot of objections, counter proposals, finally to go to DHCPv6 because we need a solution
[13:55:00] <apetrescu> FD: I don't , it's better to imrpvoe this solution than to have one new way to have PD for ocontectxt
[13:55:17] <apetrescu> TJ: not sure how the WG wants to go down the path of ... DHCPv6 is for host configuration
[13:55:35] <apetrescu> TJ: we talk delegating prefixes to router,s doesn't necessarily... not as an underlying assumption
[13:55:43] <apetrescu> FD: DHCPv6 PD I talk about, which is for routers
[13:55:52] <apetrescu> FD: a 3rd proposal: just a profile how to use DHCPv6 PD
[13:56:09] <apetrescu> FD: at least we go out current situation with two proposals satisfying nobody,
[13:56:16] <apetrescu> TJ: 'd like to see that , with security consider
[13:56:19] <apetrescu> Jean-Michel Combes
[13:56:34] <apetrescu> JMC: must take intoa ccount SeND, how the Mr will get the certs linked to the prefix it gets
[13:56:59] <apetrescu> JMC: know that HDCPV6 solutions DHC WG, there is a solution, but I didn't see anything about this when this was BU updates solution
[13:57:19] <apetrescu> TJ: there's preexisting SA between MR and HA, assumption is that some prefix or given to the MR, existing the existing SA
[13:57:38] <apetrescu> JMC: in fact MR needs some certs to prove to allow it to advertise
[13:57:55] <apetrescu> FD: if you have one usage one cert, two usage two certs, don't use same cert for many usages
[13:57:59] <apetrescu> Fred Templin
[13:58:13] <apetrescu> FT: DHCPv6 PD is about RR and DR, it's router to router, not router to host
[13:58:15] <apetrescu> FD: I agre
[13:58:38] <apetrescu> FD: how a MR can get a prefix from the visited network? It's getting prefixes from hoen and from visited, I think both are needed
[13:58:44] <apetrescu> TJ: right, right now we don't considr
[13:58:56] <apetrescu> TJ: you'd use your own admin domain, not crossing over admin domains
[13:59:07] <apetrescu> TJ: airopsace didn't look at that
[13:59:18] <apetrescu> FD: hassle over from AUTOCONF, getting a prefix from a visited adhoc network.
[13:59:28] <apetrescu> FD: SA with HA, not clear why DHCPv6 couldn't.
[13:59:31] <apetrescu> TJ: on the list
[13:59:34] <apetrescu> FD: ok
[13:59:40] <apetrescu> Sorry, last FDs are all FTs
[13:59:50] <apetrescu> JA: default DHCP, but not enough information we have
[14:00:06] <apetrescu> JA: interactions it needs to know or do, or information DHCPv6 server, relay FD said is one way
[14:02:06] --- cabo has left
[14:55:52] --- LOGGING STARTED
[14:56:54] --- yowada has joined
[14:57:01] --- yowada has left
[15:01:27] --- rjaksa has joined
[15:01:28] --- rjaksa has left
[15:04:47] --- intvelt has joined
[15:05:20] --- intvelt has left
[16:14:46] --- john.zhao has joined
[16:14:48] --- john.zhao has left
[17:55:01] --- mey has joined