headers
Jari Arkko | 2 Aug 2006 14:21

notes from the INT meeting in Montreal

Thank you Stefano and Vijay for taking notes! If there
are any additions or corrections, please send them to
either me or Mark.

---

Internet Area Meeting
IETF 66, July 2006, Montreal

Area Directors: Jari Arkko & Mark Townsley
Note takers: Vijay Devaparalli and Stefano Faccin (merged and edited by
Jari Arkko)

1. Area status update (ADs, 20 min)
===================================

BOFs: none this time, shared interest with HOKEY BOF and the NEW
BOF. LIES/TERNLI BOF did not happen, but there will a presentation on
this topic later in this meeting. One BOF on anycast was discussed,
but there was some discussion on O&M open area meeting.

WGs creation, rechartering, and termination: Created ANCP (Access Node
Configuration) and 16ng (IP over 802.16) WGs. Terminated IPOIB (IP
over InfiniBand) due to having finished its main task. MIBs remained
in their charter, but there was not enough progress on them.

MIPSHOP rechartered after it had finished all of its tasks. MIP4
being rechartered to add dual stack operations work item. MIP6 being
rechartered to consider progress and align to current interests and
the charter. NEMO and SHIM6 will undergo rechartering before IETF-67.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Vijay Devarapalli | 2 Aug 2006 16:58

Re: notes from the INT meeting in Montreal

looks good to me.

Vijay

Jari Arkko wrote:
> Thank you Stefano and Vijay for taking notes! If there
> are any additions or corrections, please send them to
> either me or Mark.
> 
> ---
> 
> Internet Area Meeting
> IETF 66, July 2006, Montreal
> 
> Area Directors: Jari Arkko & Mark Townsley
> Note takers: Vijay Devaparalli and Stefano Faccin (merged and edited by
> Jari Arkko)
> 
> 
> 1. Area status update (ADs, 20 min)
> ===================================
> 
> BOFs: none this time, shared interest with HOKEY BOF and the NEW
> BOF. LIES/TERNLI BOF did not happen, but there will a presentation on
> this topic later in this meeting. One BOF on anycast was discussed,
> but there was some discussion on O&M open area meeting.
> 
> WGs creation, rechartering, and termination: Created ANCP (Access Node
> Configuration) and 16ng (IP over 802.16) WGs. Terminated IPOIB (IP
> over InfiniBand) due to having finished its main task. MIBs remained
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julien Laganier | 7 Aug 2006 15:20
Favicon

IPv6 addressing model, per-MN subnet prefix, and broadcast domain

Hi Dave, and other folks knowledgeable about IPv6 addressing model,

[netlmm <at> ietf.org CCed, please reply only to int-area <at> ietf.org]

While working on the issues of which addressing model to use in 
NetLMM, I think I got confused with issues involved the IPv6 
addressing model (or its assumptions.)

I would therefore like to ask you if a potential NetLMM addressing 
model (per-MN subnet prefix [RFC3314]) would, in some situations, 
conflict with the IP addressing model.

Background
----------

Dave's draft on issues involved with multilink subnets 
[draft-thaler-intarea-multilink-subnet-issues] list some assumptions 
of the IP addressing model, but there might be other that are not 
specific to multilink subnets. I'd therefore like to ask you about 
possible conflicts between IPv6 and RFC3314 addressing model.

We are considering the situation of mobile nodes (MNs) attached to a 
NetLMM domain. The NetLMM domain span multiple access links, each 
served by a given access router (AR). A MN attaches to one link, and 
hence to one AR.

	( NetLMM domain )
        /   |   |   |   \
       AR   AR  AR  AR   AR
      /  \   \     /  \    \
(Continue reading)

Permalink | Reply | 81 comments |
headers
Christian Vogt | 7 Aug 2006 18:38
Picon
Favicon

Re: [netlmm] IPv6 addressing model, per-MN subnet prefix, and broadcast domain

Hi Julien,

I don't think there is a problem.

If you use the prefix-per-MN case on a broadcast link, what you get is a
link comprising multiple subnets.  RFC 3513 explicitly allows links with
multiple prefixes:

   Currently IPv6 continues the IPv4 model that a subnet prefix is
   associated with one link.  Multiple subnet prefixes may be assigned
   to the same link.

(This is, BTW, the passage that Dave Thaler cites in
[draft-thaler-intarea-multilink-subnet-issues].)

In the scenario you describe (the one including MNs A, B, and C), you
simply have a link with 3 prefixes.  The unusual, but still legitimate
circumstance in this scenario is that the MNs do not see their
neighbors' prefixes.

Note that a situation where hosts on the same link see different
prefixes may also arise when the link has multiple routers, each router
advertises a different set of prefixes, and no two hosts receive RAs
from the same router due to packet loss.  The hosts will then not be
aware of their neighbors' prefixes.  Certainly, this is unlikely to
happen, but it may happen.

Let me know if I have missed something.

- Christian
(Continue reading)

Permalink | Reply | 13 comments |
headers
marcelo bagnulo braun | 7 Aug 2006 20:01
Picon

Re: IPv6 addressing model, per-MN subnet prefix, and broadcast domain


El 07/08/2006, a las 16:20, Julien Laganier escribió:

> Hi Dave, and other folks knowledgeable about IPv٦ addressing model,
>
> [netlmm <at> ietf.org CCed, please reply only to int-area <at> ietf.org]
>
> While working on the issues of which addressing model to use in
> NetLMM, I think I got confused with issues involved the IPv٦
> addressing model (or its assumptions.)
>
> I would therefore like to ask you if a potential NetLMM addressing
> model (per-MN subnet prefix [RFC٣٣١٤]) would, in some situations,
> conflict with the IP addressing model.
>
> Background
> ----------
>
> Dave's draft on issues involved with multilink subnets
> [draft-thaler-intarea-multilink-subnet-issues] list some assumptions
> of the IP addressing model, but there might be other that are not
> specific to multilink subnets. I'd therefore like to ask you about
> possible conflicts between IPv٦ and RFC٣٣١٤ addressing model.
>
> We are considering the situation of mobile nodes (MNs) attached to a
> NetLMM domain. The NetLMM domain span multiple access links, each
> served by a given access router (AR). A MN attaches to one link, and
> hence to one AR.
>
> 	( NetLMM domain )
(Continue reading)

Permalink | Reply | 60 comments |
headers
Christian Vogt | 7 Aug 2006 20:01
Picon
Favicon

Follow-up: Re: [netlmm] IPv6 addressing model, per-MN subnet prefix, and broadcast domain

To clarify the point I want to make:

- Certainly, there is currently no mechanism that allows you to limit a
node on a broadcast link to a subset of all on-link prefixes (even
though loss of RAs may temporarily prevent the node from seeing all
on-link prefixes).

- The prefix-per-MN approach would be the first mechanism that
guarantees to permanently limit a node on a broadcast link to a subset
of all on-link prefixes.  From this perspective, the prefix-per-MN
approach does make a difference.

- But my point is that things won't break if you use the prefix-per-MN
approach on a broadcast link, because the IPv4/IPv6 architecture does
AFAICT not require nodes to be aware of all on-link prefixes.
Neighboring nodes will simply not be able to communicate directly on the
link layer because they don't consider each other "on link".  This is
what we'd like to have in NETLMM anyway.

- Christian

--

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/

"Everything should be made as simple as possible, but not simpler."
(Albert Einstein)

Christian Vogt wrote:
> Hi Julien,
(Continue reading)

Permalink | Reply | 5 comments |
headers
Narayanan, Vidya | 7 Aug 2006 20:28

RE: Follow-up: Re: [netlmm] IPv6 addressing model, per-MN subnet prefix, and broadcast domain

While it is true that IPv6 allows multiple subnets per link and has no
requirement about all nodes being aware of all prefixes, it is intended
for routers on a link supporting multiple prefixes. So, the number of
prefixes that you would actually see on a link in practice would be much
more limited than the number of prefixes you are likely to have with the
prefix-per-MN case. 

This does work fine for point-to-point links such as cellular links, but
for the general broadcast media, it is rather strange. It seems to me
that taking broadcast/multicast capability away from a medium that
natively supports the functionality is placing a serious limitation on
such links. I don't know if it specifically breaks something w.r.t IPv6,
but it definitely takes away some powerful functionality. 

Also, if, keeping inline with the charter goals, we still maintain that
the MN does not require any changes, this means that an MN, on WLAN or
ethernet or such media, will assume it is on a shared link and attempt
to do DAD - it will always succeed, but it is just a waste of resources
and time in such a prefix-per-MN model. Also, if stateful address
configuration is used, this means that the MN must do DHCP-PD, which it
normally may not do - so, that will be a change that NETLMM imposes on
an MN. 

If we are going with the prefix-per-MN model, perhaps a good thing to do
will be to scope NETLMM to virtual point-to-point links, since that is
what a broadcast link will be reduced to, in this case. 

Vidya

> -----Original Message-----
(Continue reading)

Permalink | Reply | 4 comments |
headers
Christian Vogt | 7 Aug 2006 20:50
Picon
Favicon

Re: Follow-up: Re: [netlmm] IPv6 addressing model, per-MN subnet prefix, and broadcast domain

Hi Vidya,

right, the term "virtual point-to-point link" describes very well what a
broadcast link becomes as soon as one deploys the prefix-per-MN model.

(Although neighboring MNs can still circumvent the
"pseudo-point-to-point" property by communicating via link-local IP
addresses...)

- Christian

--

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/

"Everything should be made as simple as possible, but not simpler."
(Albert Einstein)

Narayanan, Vidya wrote:
> While it is true that IPv6 allows multiple subnets per link and has no
> requirement about all nodes being aware of all prefixes, it is intended
> for routers on a link supporting multiple prefixes. So, the number of
> prefixes that you would actually see on a link in practice would be much
> more limited than the number of prefixes you are likely to have with the
> prefix-per-MN case. 
> 
> This does work fine for point-to-point links such as cellular links, but
> for the general broadcast media, it is rather strange. It seems to me
> that taking broadcast/multicast capability away from a medium that
> natively supports the functionality is placing a serious limitation on
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alexandru Petrescu | 7 Aug 2006 21:08

Re: [netlmm] IPv6 addressing model, per-MN subnet prefix, and broadcast domain

Christian Vogt wrote:
> Hi Julien,
> 
> I don't think there is a problem.
> 
> If you use the prefix-per-MN case on a broadcast link, what you get
> is a link comprising multiple subnets.  RFC 3513 explicitly allows
> links with multiple prefixes:
> 
> Currently IPv6 continues the IPv4 model that a subnet prefix is 
> associated with one link.  Multiple subnet prefixes may be assigned 
> to the same link.
> 
> (This is, BTW, the passage that Dave Thaler cites in 
> [draft-thaler-intarea-multilink-subnet-issues].)
> 
> In the scenario you describe (the one including MNs A, B, and C), you
>  simply have a link with 3 prefixes.  The unusual, but still
> legitimate circumstance in this scenario is that the MNs do not see
> their neighbors' prefixes.
> 
> Note that a situation where hosts on the same link see different 
> prefixes may also arise when the link has multiple routers, each
> router advertises a different set of prefixes, and no two hosts
> receive RAs from the same router due to packet loss.  The hosts will
> then not be aware of their neighbors' prefixes.  Certainly, this is
> unlikely to happen, but it may happen.

I think I agree with the description.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Alexandru Petrescu | 7 Aug 2006 21:13

Re: RE: Follow-up: Re: [netlmm] IPv6 addressing model, per-MN subnet prefix, and broadcast domain

Narayanan, Vidya wrote:
> While it is true that IPv6 allows multiple subnets per link and has no
> requirement about all nodes being aware of all prefixes, it is intended
> for routers on a link supporting multiple prefixes. So, the number of
> prefixes that you would actually see on a link in practice would be much
> more limited than the number of prefixes you are likely to have with the
> prefix-per-MN case. 
> 
> This does work fine for point-to-point links such as cellular links, but
> for the general broadcast media, it is rather strange. It seems to me
> that taking broadcast/multicast capability away from a medium that
> natively supports the functionality is placing a serious limitation on
> such links. I don't know if it specifically breaks something w.r.t IPv6,
> but it definitely takes away some powerful functionality. 

If the wireless media is natively point-to-point then there is no 
necessity to make it multicast capable.

To me this is the thing to be addressed, the netlmm wireless link nature.

> Also, if, keeping inline with the charter goals, we still maintain that
> the MN does not require any changes, this means that an MN, on WLAN or
> ethernet or such media, will assume it is on a shared link and attempt
> to do DAD

Not sure that the charter assumes MN being on a shared link.  I think it 
makes no assumptions of being on a shared link or on a point-to-point 
link.  It think it should, or maybe in the reqs/ps drafts.

Alex
(Continue reading)

Permalink | Reply | 0 comments |

Gmane