Subject: [mobile-ip] Subnet vs Link

From: "Jiwoong Lee" <[email-masked]>
Date: Fri, 20 Jul 2001 14:31:55 +0900

I just found that mipv6-sec-reqts-00.txt uses terminology both 'subnet' and
'link' in one document.

In some sense, I regard they are different. In other sense, I don't see any
difference. By the way, I didn't know that IPv6 also has the concept of
'subnet'.

Can anyone give me clear explanation?

Thank you
Jiwoong

---

From: Francis Dupont <[email-masked]>
Date: Fri, 20 Jul 2001 09:25:36 +0200

=> this seems to be just a mistake: I believe only the word 'link' should
be used because only the word 'link' is clearly defined in IPv6 documents.
The word 'subnet' (subnetwork in fact) is the generic 'OSI ISO' term but
its meaning for IPv4 is a bit different so it can be ambiguous.

Regards

[email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: 23 Jul 2001 10:07:37 +0200

> be used because only the word 'link' is clearly defined in IPv6

I think "subnet" is also extensively used in IPv6 rfc's.

But if we get back to original message, why are you asking this
Jiwoong?  Do you think that further differentiation subnet-link should
be made in the Threat Model draft with respect to security issues?  Or
can the draft live with the subnet-link ambiguity?

Alex

---

From: "Jiwoong Lee" <[email-masked]>
Date: Mon, 23 Jul 2001 17:40:21 +0900

Alex,

My question was quite a general one. As Francis's said, I do not have the
concept of 'IPv6 subnet' in my mind.    The authors of mipv6-sec-reqts-00
seem to use both terms intentionally. My curiosity comes from that. I felt
inclined to ask the authors, if any, unstated reasons in doing so.

BTW, I think the draft is well-written.

Regards,

Jiwoong

---

From: Alexandru Petrescu <[email-masked]>
Date: 23 Jul 2001 11:43:30 +0200

> BTW, I think the draft is well-written.

Me too, I think it's well structured and organized.  However, I'm
wondering if putting requirements into it is really necessary.  In my
understanding a Threat Model should restrict as least as possible the
solutions' space.

Take for example requirement G.1.  As I understand it (might not be
the right understanding), it requires every AR willing to play HA role
to have an SA with every visiting MN.  This is so striking to me.  A
less heavy solution, but still using crypto, could be designed that
would require the respective AR to have an SA with the MN's true HA
only.  Moreover, a functional-only solution (non crypto) would require
the AR to probe the MN with an NS before adding a binding for it, such
that if the MN responds with an NA then the AR knows it's not moved,
and the received BU is spoofed.

By eliminating this kinds of solutions, probably authors' intention
was to avoid modifications to the base mipv6, and only add some
security "salt".  I don't know.

Alex