Subject: Re: [MEXT] Home Link operation over p2p links

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 18 Feb 2008 07:43:01 -0800 (PST)

Hi Julien,
  We have submitted our draft on the prefix management for home link operation over p2p links, it is at:
http://tools.ietf.org/wg/mext/draft-sarikaya-mext-homelink-prefix-delegation-00.txt
The idea is that home link operation should deal with prefix mgmt for MN's not just for MR's.
  Regards,

Behcet

----- Original Message ----
From: Julien Laganier <[email-masked]>
To: [email-masked]
Sent: Thursday, February 14, 2008 10:24:46 AM
Subject: Re: [MEXT] Home Link operation over p2p links

Hello 
Vijay,

Thanks 
for 
submitting 
the 
draft 
in 
time! 
This 
is 
definitely 
helpful 
to 
assess 
the 
rechartering 
work 
item 
you 
proposed.

<chair 
hat 
off>

I 
have 
couple 
of 
comments 
on 
your 
draft:

3.1.  
Detecting 
Attachment 
to 
the 
Home 
Link
  
In 
Mobile 
IPv6, 
a 
mobile 
node 
detects 
that 
it 
has 
attached 
to 
the
  
home 
link 
when 
it 
receives 
a 
router 
advertisement 
with 
the 
home
  
prefix.  
Some 
of 
the 
point-to-point 
links 
like 
IPsec 
tunnels 
and
  
PMIPv6 
tunnels 
do 
not 
support 
running 
neighbor 
discovery 
in 
the
  
tunnels.  
When 
the 
home 
link 
is 
created 
by 
concatenating 
a 
GTP
tunnel 
with 
a 
PMIPv6 
tunnel 
or 
an 
IPsec 
tunnel 
with 
PMIPv6 
tunnels,
it 
becomes 
difficult 
for 
a 
router 
advertisement 
to 
be 
sent 
over 
the
concatenated 
tunnels.

When 
"concatenating 
a 
GTP 
tunnel 
with 
a 
PMIPv6 
tunnel", 
the 
RS 
can 
be 
sent 
through 
the 
GTP 
tunnel 
by 
the 
MN, 
up 
to 
the 
MAG. 
Then 
the 
MAG 
replies 
with 
an 
RA 
containing 
the 
Home 
Network 
Prefix, 
so 
there 
doesn't 
seem 
to 
be 
an 
issue. 
Am 
I 
missing 
something?

When 
"concatenating 
an 
IPsec 
tunnel 
with 
a 
PMIPv6 
tunnel", 
the 
MN 
cannot 
send 
the 
RS 
through 
the 
IPsec 
tunnel, 
and 
likewise, 
the 
MAG 
wouldn't 
be 
able 
to 
reply 
with 
an 
RA 
containing 
the 
Home 
Network 
Prefix. 
However, 
isn't 
the 
main 
issue 
at 
stake 
here 
the 
fact 
that 
IPsec 
"interfaces" 
are 
not 
fully 
fledged 
IPv6 
interface, 
i.e. 
they 
do 
not 
support 
link-local 
addresses 
and 
multicast, 
etc. 
See 
Pasi's 
draft 
describing 
the 
issues 
and 
possible 
solution:

draft-eronen-ipsec-ikev2-ipv6-config-02.txt

It 
seems 
to 
me 
that 
if 
what 
Pasi 
proposes 
was 
implemented 
in 
the 
HA 
implementing 
IKEv2, 
then 
the 
issues 
your 
draft 
describe 
w.r.t. 
detecting 
home 
link 
attachment 
would 
vanish. 
If 
that 
is 
the 
case, 
wouldn't 
the 
right 
approach 
be 
to 
fix 
IPsec 
rather 
than 
extending 
MIPv6 
because 
IPsec 
has 
a 
deficiency?

3.2.  
Bootstrapping
  
Mobile 
IPv6 
bootstrapping 
[8] 
and 
[9] 
depends 
on 
the 
use 
of 
IKEv2
  
between 
the 
mobile 
node 
and 
the 
home 
agent 
to 
bootstrap 
the 
MIPv6
  
home 
address.  
According 
to 
RFC 
3775, 
when 
the 
mobile 
node 
is
  
attached 
to 
the 
home 
link, 
it 
does 
not 
have 
to 
run 
IKEv1/IKEv2
with 
the 
home 
agent 
to 
setup 
the 
necessary 
security 
associations. 
Most 
often, 
the 
IKEv2 
exchange 
is 
triggered 
by 
the 
need 
to 
send 
a
binding 
update.  
So 
if 
the 
mobile 
node 
boots 
up 
the 
home 
link, 
it 
may
not 
be 
able 
to 
use 
IKEv2 
to 
bootstrap 
the 
MIPv6 
home 
address.

Purely 
based 
on 
RFC3775 
the 
MN 
does 
not 
have 
to 
run 
IKE 
to 
setup 
SA's 
with 
HA 
when 
it 
is 
attached 
on 
its 
home 
link 
(But 
note 
that 
here 
we're 
talking 
about 
bootstrapping 
and 
that 
wasn't 
part 
of 
3775 
so 
we 
can't 
reason 
uniquely 
in 
terms 
of 
what 
3775 
says). 
However, 
the 
only 
ways 
for 
a 
MN 
to 
figure 
out 
that 
it 
is 
attached 
on 
its 
home 
link 
are 
either 
to 
compare 
its 
home 
address 
with 
the 
prefix 
advertized 
on-link 
in 
RA's. 

In 
the 
case 
of 
bootstrapping 
the 
MN 
does 
not 
know 
its 
home 
address 
before 
hand, 
thus 
it 
can't 
conclude 
that 
it 
is 
home 
before 
it 
acquire 
a 
home 
address 
via 
bootstrapping. 

By 
default 
it 
will 
thus 
assume 
it 
is 
not 
at 
home 
and 
initiate 
bootstrapping. 
Hence 
there 
is 
a 
need 
to 
send 
a 
BU 
to 
get 
the 
Home 
Address. 
As 
you 
note 
"the 
IKEv2 
exchange 
is 
triggered 
by 
the 
need 
to 
send 
a 
binding 
update", 
thus 
I 
assume 
IKEv2 
would 
be 
triggered 
to 
acquire 
an 
home 
address.

Then 
the 
MN 
can 
conclude 
it 
is 
home 
(because 
HoA 
included 
in 
RA's 
PIO) 
and 
drop 
the 
IKE 
and 
IPsec 
association.

It 
is 
true 
that 
it 
isn't 
written 
down 
but 
to 
me 
it 
looks 
logical 
that 
an 
implementor 
would 
follow 
these 
steps. 
Do 
you 
think 
such 
a 
procedure 
is 
inappropriate?

The 
IKEv2 
exchange 
is 
only 
used 
to 
bootstrap 
the 
MIPv6 
home
address. 
The 
DS-MIPv6 
[11] 
IPv4 
home 
address 
is 
obtained 
by 
the
mobile 
node 
using 
the 
exchange 
of 
Binding 
Update 
and 
Binding
Acknowledgement 
with 
the 
home 
agent.  
The 
Mobile 
Network 
Prefixes
required 
for 
mobile 
router 
operation, 
as 
described 
in 
[10], 
may 
also
obtained 
using 
the 
Binding 
Update 
and 
Binding 
Acknowledgement
exchange 
between 
the 
mobile 
router 
and 
the 
home 
agent.  
This 
is
specified 
in 
[12]. 
According 
to 
the 
current 
specifications, 
the
mobile 
node 
(or 
the 
mobile 
router) 
does 
not 
send 
a 
Binding 
Update 
to
the 
home 
agent 
when 
it 
is 
attached 
to 
the 
home 
link.

Regarding 
IPv4 
home 
address 
allocation, 
the 
same 
reasoning 
applies 
as 
with 
bootstrapping 
of 
the 
MIPv6 
home 
address 
above: 
there 
would 
be 
a 
need 
to 
send 
a 
BU 
(to 
get 
the 
IPv4 
HoA) 
thus 
IKE 
would 
be 
triggered, 
and 
dropped 
down 
once 
the 
v4 
address 
is 
known.

Regarding 
Mobile 
Network 
Prefix 
Assignment, 
there's 
no 
agreement 
yet 
whether 
this 
is 
done 
with 
extensions 
to 
BUs 
and 
BAs, 
or 
using 
DHCP. 
If 
it 
was 
done 
using 
DHCP 
it 
could 
work 
provided 
that 
DHCP 
requests 
can 
be 
sent 
thru 
the 
point-to-point 
link. 
Francis 
has 
proposed 
a 
method 
where 
a 
DHCP 
relay 
is 
collocated 
on 
the 
MR, 
and 
thus 
only 
unicast 
DHCP 
messages 
have 
to 
be 
sent 
and 
received. 
Therefore 
it 
would 
work 
well 
on 
a 
point-to-point 
link.

Since 
it 
is 
not 
typical 
for 
the 
mobile 
node 
to 
initiate 
an 
IKEv2
  
exchange 
with 
its 
home 
agent 
and 
not 
possible 
to 
send 
a 
Binding
  
Update 
from 
the 
home 
link, 
there 
is 
a 
need 
for 
other 
bootstrapping
  
mechanisms 
that 
would 
work 
across 
all 
point-to-point 
home 
links.
  
However, 
this 
would 
result 
in 
the 
mobile 
node 
using 
different
  
bootstrapping 
mechanisms 
depending 
on 
the 
point-to-point 
that
appears 
as 
the 
home 
link.  
The 
mobile 
node 
would 
also 
end 
with 
using
different 
bootstrapping 
mechanisms 
when 
attached 
to 
the 
home 
link 
and
when 
attached 
to 
the 
visited 
link.  
To 
avoid 
this, 
it 
would 
be
desirable 
to 
use 
the 
same 
bootstrapping 
mechanisms 
irrespective 
of
the 
point-to-point 
link 
that 
appears 
as 
the 
home 
link 
and/or 
the
visited 
link.

But 
it 
looks 
like 
the 
same 
IKEv2 
based 
bootstrapping 
mechanism 
is 
used 
in 
everycase, 
it 
is 
just 
that 
once 
the 
MN 
figures 
out 
it 
is 
at 
home 
it 
can 
drop 
the 
IKE 
and 
IPsec 
SA's.

3.4.  
Forwarding 
at 
the 
Home 
Agent
  
According 
to 
RFC 
3775, 
when 
the 
mobile 
node 
is 
attached 
to 
the
home 
link, 
it 
behaves 
as 
a 
regular 
IPv6 
host 
and 
is 
able 
to
send/receive 
packets 
directly 
without 
going 
through 
the 
home 
agent. 
In 
case 
the 
home 
agent 
needs 
to 
send 
any 
packet 
to 
the 
mobile 
node,
it 
has 
a 
valid 
neighbor 
cache 
entry 
for 
the 
mobile 
node 
which 
is 
then
used 
to 
forward 
packets 
to 
the 
mobile 
node.
  
When 
point-to-point 
links 
are 
used 
a 
home 
links, 
then 
the 
packets
  
meant 
for 
the 
mobile 
node 
always 
reach 
the 
home 
agent 
first 
and
are 
then 
forwarded 
to 
the 
mobile 
node.  
However, 
the 
home 
agent
cannot 
construct 
a 
neighbor 
cache 
entry 
for 
the 
mobile 
node, 
since
most 
of 
the 
point-to-point 
links 
mentioned 
in 
Section 
1 
do 
not
support 
sending 
neighbor 
solicitation 
and 
receiving 
neighbor
advertisement 
messages.

Again, 
if 
IPsec 
was 
fixed 
as 
in 
Pasi's 
proposal 
then 
it 
would 
work 
just 
fine. 
Other 
point-to-point 
links 
happily 
carry 
multicast 
traffic.

3.5.  
Indicating 
Service 
Selection 
Option
  
A 
new 
extension, 
the 
Service 
Selection 
for 
Mobile 
IPv6, 
has 
been
  
specified 
in 
[13] 
for 
the 
mobile 
node 
to 
indicate 
to 
the 
home
agent 
which 
service 
it 
wants 
to 
access.  
The 
Service 
Selection 
option
is 
sent 
in 
the 
Binding 
Update.  
When 
the 
mobile 
node 
boots 
up 
in 
the
home 
link, 
it 
won't 
be 
able 
to 
indicate 
the 
service 
it 
wants 
to
access 
to 
the 
home 
agent, 
since 
the 
Binding 
Update 
message 
is 
not
sent 
from 
the 
home 
link.
  
It 
is 
possible 
to 
indicate 
the 
Service 
the 
mobile 
node 
wants 
to
  
access 
in 
the 
IKEv2 
exchange 
with 
the 
home 
agent.  
The 
service
  
information 
is 
encoded 
in 
the 
IDr 
payload 
in 
the 
IKEv2 
exchange.
  
However, 
this 
requires 
the 
mobile 
node 
to 
initiate 
an 
IKEv2
exchange 
with 
the 
mobile 
node 
from 
the 
home 
link.  
According 
to 
RFC
3775, 
the 
mobile 
node 
does 
not 
have 
to 
initiate 
an 
IKEv2 
exchange
when 
it 
boots 
up 
in 
the 
home 
link.

Same 
goes 
here 
than 
for 
bootstrapping. 
There's 
indeed 
a 
need 
to 
send 
a 
BU, 
so 
does 
the 
MN, 
then 
IKEv2 
kicks 
in, 
BU 
is 
sent 
out, 
and 
no 
problem.

In 
conclusion 
I 
am 
not 
sure 
there's 
a 
clear 
case 
to 
extend 
MIPv6. 
Maybe 
there's 
some 
room 
for 
a 
document 
clarifying 
how 
implementation 
should 
behave 
with 
bootstrapping 
while 
on 
the 
home 
link.

What 
do 
you 
think?

Best,

--julien

On 
Wednesday 
13 
February 
2008, 
Vijay 
Devarapalli 
wrote:
Hello 
folks,
Here 
is 
a 
draft 
that 
describes 
issues 
with 
the 
mobile 
node
booting 
up 
on 
the 
home 
link 
over 
point-to-point 
links. 
It
describes 
the 
issues 
and 
suggests 
a 
possible 
solution.
http://www.ietf.org/internet-drafts/draft-devarapalli-mext-mipv6-home
>-link-00.txt
Comments/reviews 
are 
welcome.
Vijay
_______________________________________________
MEXT 
mailing 
list
[email-masked]
http://www.ietf.org/mailman/listinfo/mext

_______________________________________________
MEXT 
mailing 
list
[email-masked]
http://www.ietf.org/mailman/listinfo/mext

_______________________________________________
MEXT mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mext