Subject: [Autoconf] Subnet definition

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 19 Nov 2008 18:15:41 -0800

Hello folks,

I'd like to propose the following two definitions.

A "subnet" is a contiguous range of IP addresses that
admits a routing prefix.

A "subnet router" is a router that provides access to
any node that uses one of the contiguous IP addresses
belonging to the range of the subnet.

==================================

However, there may be "routers" that do not
make any such claim about routing to a subnet.

In general, routers may forward packets to
nodes that are on link but not part of any
subnet for which the router provides access.
This model of routing  allows for a router to
forward a packet to a node that is NOT on
a subnet.

It is my belief that these "non-subnet" routers
are a crucial component of MANET routing,
and that the attempt to fit them into any
reasonable model of "subnet router" is
doomed to frustration and failure.

Regards,
Charlie P.

PS. I am resending this since the first attempt
      did not succeed... sorry if there is
      duplication.

_______________________________________________
Autoconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/autoconf

---

From: "Seung Yi" <[email-masked]>
Date: Wed, 19 Nov 2008 21:06:56 -0800

> belonging to the range of the subnet.
/snip/

Somewhat related to Charlie's posting, there is one thing I've been
curious about for a while but couldn't find a definite answer to:

"Why was the concept of the "subnet" introduced in the first place?"

I think the story might be something like this. First, there was an
Ethernet segment (or something similar), which is an L2 concept. One
of the characteristics of an Ethernet segment is, when one node on the
segment sends something, every other nodes on the segment can
hear/receive that. To abstract that concept (that I can reach everyone
by simply relying on L2 facility) in L3, one introduces the concept of
the "subnet". By carefully assigning IP addresses from a subnet range
to all nodes on a single Ethernet segment, one can enable L3
communication between them without having to run a routing protocol.
So, the concept of the "subnet" seems nothing but an artificial
construct one uses in L3 to abstract underlying L2 connectivity.

Moving back to MANET,

   - If a MANET is running some sort of L2 routing protocol and
presents an Ethernet-like view of L2 to L3, it is fine to assign IP
addresses from a subnet range. Everything should work as in an
Ethernet segment. (To my understanding, this is how some of military
IP radios work).
   - If there is no such L2 routing available and all L2 can do is
something like 802.11 ad-hoc mode, you can still assign IP addresses
from a subnet range to MANET routers if you want. However, you will
get a multi-link subnet as the result. ND will find all other nodes in
range but not all other nodes in the subnet. Link-local multicast will
reach only the nodes in range, but not all the nodes in the subnet. If
you have a way to handle multi-link subnet, that this is fine.
   - Finally, you can assign IP addresses to each MANET router so that
every node belongs to its own singleton subnet. ND and link-local
multicast will work correctly. Only they cannot be used as MANET-wide
communication primitives.

If my original guess about the concept of the "subnet" is correct, any
of these three options seems like an acceptable choice for the IP
address assignment scheme. Still, lot of people on the list seems to
be arguing for one or the other. Are there really a good reason to
discount any of these choices?

Thanks,

- Seung

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 20 Nov 2008 06:18:43 +0100

> A "subnet" is a contiguous range of IP addresses that

Why not using the term routing prefix for a routing prefix?

> belonging to the range of the subnet.

If we stick on MANET, we discuss only router related topics, agreed?

And routers do provide routes to destinations, OK?

I have to think more about this, but for now I can't see a problem.

Teco.

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 20 Nov 2008 06:45:28 +0100

> Ethernet segment. (To my understanding, this is how some of military

We should not make too many assumptions.
For example, even the 802.11 standard specifies you cannot assume all STAs
are connected.
You are right, some of the military provide something similar to an Ethernet
segment. Others don't.

> you have a way to handle multi-link subnet, that this is fine.

Why should we assign IP addresses from a subnet to MANET interfaces? Routing
works well without, using link local addresses. Routers usually support a
loopback interface. Just configure a host prefix on the loopback and we are
done.

> communication primitives.

Why can't these addresses be used? Routers provide reachability for
prefixes, or am I missing something?

Teco.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 19 Nov 2008 22:43:51 -0800

Hello Teco,

> Why not using the term routing prefix for a routing prefix?

There are two important answers to this question.
1. A subnet is something that needs definition so that we
    can avoid confusion.  No one has been getting confused
    about what a routing prefix is supposed to mean.
2. A subnet is a collection of network nodes, and a routing
    prefix is a number and a length.  But you correctly point
    out that the definition should probably be improved.

Perhaps the following definition is better:
   A "subnet" is a collection of network nodes whose addresses are
   all within a contiguous range of IP addresses that admits a routing
   prefix.

Anyway, even if the elements of two sets have a
natural one-to-one correspondence, we can still
usefully consider and understand their differences.

> And routers do provide routes to destinations, OK?

It seems to me that there has been a lot of confusion about
routers and subnets, and I think we could go forward faster
if we could manage to resolve that confusion.

Sometimes you have to enlarge the field of view in order
to see the elephant in the room (to mix metaphors :-)

Regards,
Charlie P.

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 20 Nov 2008 13:37:25 +0100

Hi Charlie,

>    all within a contiguous range of IP addresses that admits a routing
 
I am not sure on this definition. Assume a site with a /48 prefix length,
and many Ethernet segments connected with routers, would you say that the
site is a /48 subnet? Or a bundle of /64 subnets, with a subnet on each
Ethernet segment? Both?

Correct me if I am wrong, but I think it is a bundle of subnets (RFC940 /
RFC4291 / I-D.6man-ipv6-subnet-model).

With mobility in mind, I think we are working with a model that each
object_moving_as_a_whole may have a set of subnets. This would make sure
subnets don't break. Of course subnets are not assigned to multiple of those
objects, but this is BCP. I kept anycast out-of-scope.

> >> belonging to the range of the subnet.

Keeping prefix assignment is mind, do you mean that a subnet_router is a
router assigned and configured a subnet prefix to one of its interfaces? I
can agree on this definition.

Within the scope of MANETs, we should define that subnet prefixes are not
assigned to multiple routers, that are not part of the same
object_moving_as_a_whole. Agreed on that?

Regards, Teco

---

From: Thomas Narten <[email-masked]>
Date: Thu, 20 Nov 2008 09:39:38 -0500

I agree that we need a clean definition of subnet. The term is
overloaded and different people have different meanings associated
with it. That has contributed to confusion in the discussions...

Note also that I think Erik's observation about "on-link" being a key
issue to also be clear about is correct.

> A "subnet" is a contiguous range of IP addresses that

I'd change that as follows (to highlight the properties that are
important to us):

A "subnet" is the range of IP addresses that are covered by a
prefix. All that a subnet defines is which addresses are considered to
be on the subnet and which are not.

In many cases (in IPv4) there is a one-to-one mapping between a subnet
and a link. I.e., on an Ethernet, you assign a subnet to the ethernet
link.  All the addresses covered by the prefix are assumed to reside
on that Ethernet, and are neighbors of each other. Using IPv6
terminology, we would say "link" rather than subnet and we would say
all the addresses covered by the subnet are "on link". (But note that
in IPv6, you can have links with addresses assigned to it, but for
which there is no prefix that is considered "on link".)

But if one talks to routing folk, a subnet is an abstraction that is
not tied to a physical link. For example, IBM has been assigned net
9.0.0.0. So, to BGP, 9.0.0.0/8 is a "subnet", even though the actual
network is a huge cloud of thousands of individual networks.

And, within IBM, talking about 9.0.0.0/8 as a "subnet" makes little
sense, because we see the individual links that have been subnetted
and given individual subnet numbers. We talk about 9.2.27.0/24 and the
like.

Thus, when talking about a subnet, we also have to consider the
on-link properties (if any), as differing assumptions on that point
can lead to very different ideas about how things do (or don't) work.

Back to the simple Ethernet, all the addresses covered by the prefix
are typically considered on-link.

When talking about MANETs, and talking about subnets (or prefixes) we
also have to talk about the on-link properties (or lack thereof).

For example, going back to chart 37 of ThomasC's presentation, it may
well make sense to consider the entire cloud of routers to be part of
one subnet, but it does not make sense (I assume) to consider that
same subnet to be "on-link" anywhere within that cloud. Within the
cloud, the subnet is further subdivided into smaller subnets. Each of
those individual (smaller) subnets may well have on-link properties
for small portions of the overall cloud. 

Thomas

---

From: "Seung Yi" <[email-masked]>
Date: Thu, 20 Nov 2008 07:40:38 -0800

Teco,

> loopback interface. Just configure a host prefix on the loopback and we are

I actually tried using the loopback interface. It's not as
straightforward as it seems. For example, binding an application to
use the address on the loopback is not very simple without modifying
the app.
The point I tried to make here was that I don't see any reason to
prohibit assigning IP addresses from a subnet range to MANET
interfaces.

> prefixes, or am I missing something?

By "they", I meant "ND and link-local multicast". I tried to say "ND
and link-local multicast" cannot be used as MANET-wide communication
primitives. There is no problem with address assignments.

A more general point, I think, was I don't see anything wrong with any
of these three address assignment schemes. They can all be made to
work with other supporting mechanisms.
_______________________________________________
Autoconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/autoconf

---

From: "Seung Yi" <[email-masked]>
Date: Thu, 20 Nov 2008 07:46:06 -0800

On Thu, Nov 20, 2008 at 6:39 AM, Thomas Narten <[email-masked]> wrote:
>>>>>> snip <<<<<<<<<<

That is exactly what I tried to convey. It may be just a happy
coincidence that there is one-to-one mapping between a subnet and an
Ethernet link. As long as we do not assume such mapping should always
exist and treat a subnet as just a contiguous range of IP addresses
(therefore an abstract concept rather than being tied to any L2
facility), everything looks straightforward to me.

- Seung

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 20 Nov 2008 07:45:53 -0800

Seung,

>-----Original Message-----
>From: Seung Yi [mailto:[email-masked]]
>Sent: Thursday, November 20, 2008 7:41 AM
>To: Teco Boot
>Cc: [email-masked]
>Subject: Re: [Autoconf] Subnet definition
>
>Teco,
>

First, you are talking about IPv4 here; not IPv6. Second, it
doesn't have to be a loopback interface; it could be an Ethernet
for example.

Please see also Dave Thaler's discussion on strong vs weak end
system model from the plenary.

Fred
[email-masked]

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 20 Nov 2008 17:17:27 +0100

> use the address on the loopback is not very simple without modifying

Are we discussing a RFC3484 compliant router?

> primitives. There is no problem with address assignments.

You described a problem with MANET-wide communications and problems.
Did you mean that with LL addresses you cannot reach the whole MANET / whole
Internet?
This is by definition. Or am I missing something?

Teco.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 20 Nov 2008 08:36:10 -0800

Hello Teco,

> site is a /48 subnet? Or a bundle of /64 subnets, with a subnet on each

By the above definition, they are all subnets, and the site router
is a subnet router for a /48 subnet.  The site router then delegates
responsibility for some (or all) of the nodes at the site to subnet
routers that route to smaller subnets.

> RFC4291 / I-D.6man-ipv6-subnet-model).

I didn't find the term "bundle".  But anyway I think you are correct,
and that the only extra piece is that a subnet can have sub-subnets
which themselves satisfy the definition of subnet.

> objects, but this is BCP. I kept anycast out-of-scope.

Anycast does not need definition in order for use to
understand what subnet should mean.

> can agree on this definition.

Yes, that is correct.  But, and very importantly, if a router accepts this
delegation, it has the responsibility for keeping track of network nodes
using any of the addresses in the subnet.  Otherwise, the host may be
subject to becoming unreachable.
> object_moving_as_a_whole. Agreed on that?

This is not relevant.  A group of routers may share responsibility
for a subnet, for instance using VRRP or some redundancy
protocol.  IPv6 allows multiple routers to advertise reachability
to the same subnet.  Mobility of the subnet only has the effect
of making it more difficult to discharge the responsibility.  It
should not affect the basic definition or intuition of a subnet.

Regards,
Charlie P.

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Thu, 20 Nov 2008 17:42:08 +0100

Hello Charlie, all, 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Charles E. Perkins
> Sent: donderdag 20 november 2008 7:44
> To: Teco Boot
> Cc: [email-masked]
> >> A "subnet" is a contiguous range of IP addresses that admits a 
> >> routing prefix.
> >>     
> >

According to draft-iab-ip-model-evolution-01 by Dave Thaler: 'A "subnet"
in the IP service model refers to the topological area within which
addresses from the same subnet prefix are assigned to interfaces.'

Don't see much wrong with that definition.

Ronald
> 
> Anyway, even if the elements of two sets have a natural 
> one-to-one correspondence, we can still usefully consider and 
> understand their differences.
> 
> 
> 
> >
> >   
> >> A "subnet router" is a router that provides access to any 
> node that 
> >> uses one of the contiguous IP addresses belonging to the 
> range of the 
> >> subnet.
> >>     
> >
> Sometimes you have to enlarge the field of view in order to 
> see the elephant in the room (to mix metaphors :-)
> 
> Regards,
> Charlie P.
> 
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 20 Nov 2008 08:42:56 -0800

>From: Charles E. Perkins [mailto:[email-masked]]
>Sent: Thursday, November 20, 2008 8:36 AM
>To: Teco Boot
>Cc: [email-masked]

Does it configure and respond to a subnet router anycast address then?

Fred
[email-masked]

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 20 Nov 2008 17:44:57 +0100

> facility), everything looks straightforward to me.

I want to make clear that such assumptions are in contradiction with the IP
model.
RFC4903 Multi-Link Subnet Issues:  
   A multi-link subnet model should be avoided.  IETF working groups
   using, or considering using, multi-link subnets today should
   investigate moving to one of the other models.
<<<
This applies to both IPv4 and IPv6. Read RFC4903 for details. I currently
see no reason for an exception.
But of course I could be wrong.

Site remark: anycast is out-of-scope in this discussion, for obvious
reasons.

Teco.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 20 Nov 2008 08:54:28 -0800

>From: Teco Boot [mailto:[email-masked]]
>Sent: Thursday, November 20, 2008 8:45 AM
>To: [email-masked]; 'Thomas Narten'
>Cc: [email-masked]

Subnet router anycast address is an RFC4291-required address
for subnet routers. Are we talking about a different kind of
"subnet router"?

Fred

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 20 Nov 2008 18:17:56 +0100

Hi Charlie,

> routers that route to smaller subnets.
 
If this router has the /48 prefix assigned to one of its interfaces, yes I
agree.
With the longest match rule, all packets for destinations on the other
subnets (or aggregation prefixes) are forwarded to a nexthop router. The
remaining address blocks could be used for addresses on this link. SLAAC
cannot be used in this model (i.e. no /64 prefix length). 

If this router has the /48 prefix NOT assigned to one of its interfaces, NO,
I do not agree.

In my BRDP solution I use something similar, but maybe more practical. I
suggest a /64 on the BR MANET interface (could be a /128 also, but /64
better fits current text on SLAAC). MANET Routers may generate a /128 host
prefix. The longest match rule guarantees that packets are delivered to the
destination.

> which themselves satisfy the definition of subnet.

Sorry, I meant a "set of". 
And no, I do not totally agree on sub-subnet. Prefixes and sub-prefixes are
OK for me.
Only a prefix "bound" to an interface makes it a subnet.

> subject to becoming unreachable.

Agreed on that subnets SHOULD NOT be delegated?

> should not affect the basic definition or intuition of a subnet.
 
I think this is essential. VRRP will not work in a MANET, if the VRRP
Routers are part of different object_moving_as_a_whole. This would break the
subnets. I suggest not get into split subnet repair mechanisms.

Teco.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 20 Nov 2008 09:20:40 -0800

Hello Ronald,

> addresses from the same subnet prefix are assigned to interfaces.'

This also is O.K. with me, as long as we don't have
to get bogged down in defining "topological area"
and "assignment".   But I'd be happy if consensus
settles on this definition (soon).

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 20 Nov 2008 09:27:48 -0800

Hello Fred,

You raise a very interesting point!

Templin, Fred L wrote:
>
>>       ..............  the site router

In order to conform to RFC 4291, it needs to do this.

For this purpose, it might be most convenient for a site
router to avoid overlapping the anycast address ranges
for any sub-subnet.

Otherwise, by the rules of anycast, two routers at the
same anycast address have to decide how to do the
right thing (e.g., see RFC 2526).

Regards,
Charlie P.

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 20 Nov 2008 18:37:01 +0100

> for subnet routers. Are we talking about a different kind of

Sorry, I meant non-LL anycast. Those prefixes may be assigned to interfaces
of routers that are not on the same link.

Teco.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 20 Nov 2008 12:15:50 -0800

Hello Thomas,

Continuing the discussion [thanks for joining in]...

> with it. That has contributed to confusion in the discussions...

Here, I definitely agree.

> issue to also be clear about is correct.

I'm a bit nervous about this one.  I can't be comfortable until
I know what kind of link is under discussion.

> be on the subnet and which are not.
I definitely agree with this.
> network is a huge cloud of thousands of individual networks.
This is a crucial observation, which we should keep in mind
throughout the discussion.

> also have to talk about the on-link properties (or lack thereof).

Here is where I start to get nervous again.

> same subnet to be "on-link" anywhere within that cloud.

I agree with this, but I worry that there is still room for
confusion.  For instance, what if the entire cloud of routers
is NOT part of one subnet, purely for the reason that no
one router can be reasonably expected to offer connectivity
to the entire cloud?

Furthermore, under many reasonable scenarios, we ought
to continue to allow for hosts with IP addresses that are
NOT part of the subnet prefix to still get service from the
cloud.

Regards,
Charlie P.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Nov 2008 16:19:18 -0800

> construct one uses in L3 to abstract underlying L2 connectivity.

I went a looked over some old documents. A hopefully not too biased note 
of what I found:

The term "subnet" appears to have been first used in RFC917 and other 
work that lead to RFC950. That was when the classful (A, B, and C) 
network numbers were carved up into smaller "subnets" for administrative 
or technical reasons.

RFC1122 depicts the resulting IP address notation as
             We now summarize the important special cases for Class A, B,
             and C IP addresses, using the following notation for an IP
             address:

                 { <Network-number>, <Host-number> }

             or
                 { <Network-number>, <Subnet-number>, <Host-number> }

The term subnet is also used in CIDR (RFC1519) where "variable-length 
subnets" is introduced. This is the notion that different pieces of a 
Class-A/B/C network can have different number of bits in the subnet-number.

The IPv6 addressing architecture (starting with RFC 1884 and continuing 
to RFC4291) defines "subnet prefix" as N leading bits of an IPv6 
address, and also states that
    Currently, IPv6 continues the IPv4 model in that a subnet prefix is
    associated with one link.  Multiple subnet prefixes may be assigned
    to the same link.
Thus there seems to be an assumption that a subnet can not span more 
than one link, but there doesn't seem to be any statements to that 
effect any RFCs prior to RFC1884.

If we look at the earlier work for IPv4 on what is considered to be 
"on-link" e.g., for which addresses one would use ARP, it is interesting 
to note that ARP (RFC826) does not use the term "subnet" at all. Instead 
it describes things using "next hop":
	As a packet is sent down through the network layers, routing
	determines the protocol address of the next hop for the packet
	and on which piece of hardware it expects to find the station
	with the immediate target protocol address.  In the case of the
	10Mbit Ethernet, address resolution is needed and some lower
	layer (probably the hardware driver) must consult the Address
	Resolution module (perhaps implemented in the Ethernet support
	module) to convert the <protocol type, target protocol address>
	pair to a 48.bit Ethernet address.

RFC1122 doesn't use the term "subnet" for the next-hop determination 
either. Instead section 3.3.1.1 talks about an "address mask" and a 
"subnet number", that is, "subnet number" remains an address allocation 
notion.

At some point in time the ifconfig command in BSD got a "netmask" 
subcommand. It is interesting to note that it wasn't called a 
"subnetmask", even though today it might be casually viewed as such. I 
don't have the first version of the man page for ifconfig, but this 
description might be fairly old:
          Specify  how  much  of  the  address  to
          reserve  for  subdividing networks into subnetworks. The
          mask includes the network part of the local address  and
          the  subnet  part, which is taken from the host field of
          the address.

At some point folks started assigning multiple subnet prefixes to a 
single Ethernet. TBD: Find the term that was used for this.

When IPv6 was developed the de-facto terminology seemed to be that 
"subnet" refered to both an address allocation notion and the piece of 
topology to which a subnet prefix is assigned. That might have been why 
RFC1883 ended up defining tthe term "link" and RFC1884 defining "subnet 
prefix". The reason for wanting to keep those separate was that with 
IPv6 we wanted to codify the existing IPv4 practice of "assigning 
multiple subnets to a subnet", that is, assigning multiple address 
prefixes to a link.

Neighbor Discovery (RFC1970 through RFC4861) took things one step 
further by allowing separation of the address prefixes that are viewed 
as on-link (directly reachable without going through a router) and the 
address prefixes that can be used for stateless address 
autoconfiguration. Neighbor Discovery thus allows links to have no 
on-link prefixes at all (except for the link-local prefix). However, the 
Duplicate Address Detection functionality only checks for duplicates 
against the nodes that are on-link.

---

Given the old de-facto use of "subnet" to mean both "Data Link 
subnetwork" (RFC1937) i.e., what we today call "link" and an address 
prefix, it makes sense to stay away from the unqualified term "subnet".

Given the IPv6 addressing architecture seemingly assuming that a "subnet 
prefix" is on-link ("associated with one link"), perhaps we should not 
use "subnet prefix" to refer to an address prefix that is assigned to a 
collection of links, for the same reason that we don't call a /48 prefix 
a subnet prefix.

    Erik

---

From: "Seung Yi" <[email-masked]>
Date: Sun, 23 Nov 2008 16:23:02 -0800

Great summary, Erik. This was exactly what I had in mind but didn't
have a chance to do myself. I really appreciate your taking time.

> The IPv6 addressing architecture (starting with RFC 1884 and continuing to
> RFC4291) defines "subnet prefix" as N leading bits of an IPv6 address, and
> also states that
> Thus there seems to be an assumption that a subnet can not span more than
> one link, but there doesn't seem to be any statements to that effect any
> RFCs prior to RFC1884.
>

So, there are documents that explicitly map a link and a subnet. I'm
just curious. Have you run into any document that actually states
"IPv4 model" mentioned in above sentence?

Thanks,

- Seung

---

From: "Seung Yi" <[email-masked]>
Date: Sun, 23 Nov 2008 16:29:38 -0800

A bit late reply. :)

> Are we discussing a RFC3484 compliant router?

Well, I was not, actually. Just re-read 3484 and it seems to be
addressed in there. Any clue if RFC 3484 is implemented somewhere
already?

> This is by definition. Or am I missing something?

No. You're right that it is according to definition. I was commenting
that we might need to provide a MANET-wide replacement for what ND
does on a link for various reasons.
_______________________________________________
Autoconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/autoconf

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 23 Nov 2008 16:46:26 -0800

> "IPv4 model" mentioned in above sentence?

I didn't find any RFCs prior to RFC1884 that explictly talked about the 
IPv4 model. RFC950 does state that the subnets correspond to a "LAN 
cable" and has an algorithm that is based on comparing whether the 
destination is part of the local 'address&mask'.

The evolution to allow multiple subnet prefixes on a one physical 
network isn't defined in an RFC AFAICT; it was something that was done 
in various products.

    Erik

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 24 Nov 2008 08:47:35 +0100

Hi Seung,

> does on a link for various reasons.

I am not sure to go in that direction. All kind of scoping makes the
addressing architecture complex.

Teco.

---

From: "Emmanuel Baccelli" <[email-masked]>
Date: Mon, 24 Nov 2008 09:40:52 +0100

Hi Erik,

On Mon, Nov 24, 2008 at 1:46 AM, Erik Nordmark <[email-masked]>wrote:

> IPv4 model. RFC950 does state that the subnets correspond to a "LAN cable"
> and has an algorithm that is based on comparing whether the destination is
> part of the local 'address&mask'.
>
> The evolution to allow multiple subnet prefixes on a one physical network
> isn't defined in an RFC AFAICT; it was something that was done in various
> products.
>
>   Erik
>

Thanks. So unless someone objects, there is indeed a consensus on the terms
below. The only question (raised by Charlie) was about the term "subnet",
but it is cleared with pointers to RFC1884 and RFC950 indicated by Erick:

- a prefix defines a contiguous range of IP addresses.- a subnet is a set of
IP addresses (that may or may not be a prefix)
that are on the same link. These addresses are then on-link with
respect to this link. All other addresses are off-link.
- a link is what lower layers reach without TTL decrement, through a given
interface.

Let's try these as starting points.
cheers
Emmanuel
_______________________________________________
Autoconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/autoconf

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 24 Nov 2008 10:50:13 +0100

- a prefix defines a contiguous range of IP addresses.

- a subnet is a set of IP addresses (that may or may not be a prefix)

OK, but still I think the definitions are vague.

For example, the term prefix is has restrictions in range (^2 block). Let's
xref to RFC4291 here. 

And in this RFC (which is Standards Track), "subnet" has a very different
meaning than what is often suggested on this ML.

On subnet: "may or may not". I think this makes the "definition" extremely
vague.

Why can't we use RFC2460 / RFC4861 terminology?

 prefix      - a bit string that consists of some number of initial

                 bits of an address.

  link        - a communication facility or medium over which nodes can

                 communicate at the link layer, i.e., the layer

                 immediately below IP.  Examples are Ethernets (simple

                 or bridged), PPP links, X.25, Frame Relay, or ATM

                 networks as well as Internet-layer (or higher-layer)

                 "tunnels", such as tunnels over IPv4 or IPv6 itself.

   interface   - a node's attachment to a link.

RFC4291 defines what a "subnet prefix" and a "subnet ID" is. Text is
somewhat too long to include here.

On link, we could borrow from a L2-link definition for 802.11-2007:

3.76 link: In the context of an IEEE 802.11 medium access control (MAC)
entity, a physical path consisting

of exactly one traversal of the wireless medium (WM) that is used to
transfer an MAC service data unit

(MSDU) between two stations (STAs).

IPv6-link: In the context of IPv6 addressing architecture [RFC4291], a
logical path consisting

of exactly one traversal of link layer communication facility that is used
to transfer an IP packet between two IP nodes without decrementing Lop
Limit.

Teco.

cheers

Emmanuel

---

From: "Emmanuel Baccelli" <[email-masked]>
Date: Mon, 24 Nov 2008 11:50:45 +0100

Hi Teco,
OK Let's refine.

On Mon, Nov 24, 2008 at 10:50 AM, Teco Boot <[email-masked]> wrote
>
> *On subnet: "may or may not". I think this makes the "definition"
> extremely vague.*
>
> * *
>
I agree, let's remove it.

> **
>
> *Why can't we use RFC2460 / RFC4861 terminology?*
>
> *   *
>
> * prefix      - a bit string that consists of some number of initial*
>
> *                 bits of an address.*
>
> *  *
>
> *  link        - a communication facility or medium over which nodes can*
>
> *                 communicate at the link layer, i.e., the layer*
>
> *                 immediately below IP.  Examples are Ethernets (simple*
>
> *                 or bridged), PPP links, X.25, Frame Relay, or ATM*
>
> *                 networks as well as Internet-layer (or higher-layer)*
>
> *                 "tunnels", such as tunnels over IPv4 or IPv6 itself.*
>
> * *
>
> *   interface   - a node's attachment to a link.*
>
> * *
>
> *RFC4291 defines what a "subnet prefix" and a "subnet ID" is. Text is
> somewhat too long to include here.*
>
> * *
>

Yes. This is too vague compared to the earlier references pointed out by
Erick (RFC1884 and RFC950). I think we have to be clear on this, so I'd
rather stick with we have for now.

> **
>
> *On link, we could borrow from a L2-link definition for 802.11-2007:*
>
> *IPv6-link: In the context of IPv6 addressing architecture [RFC4291], a
> logical path consisting*
>
> *of exactly one traversal of link layer communication facility that is
> used to transfer an IP packet between two IP nodes without decrementing Lop
> Limit.*
>
> * *
>
> *Teco *
>

I guess this is a routing-based definition, talking about a path. We are
rather trying to have a definition based on the addressing scheme, so maybe
we could talk about a scope instead? We would then have the following:

- a prefix defines a contiguous range of IP addresses, represented by the
initial bit string common to all these addresses (as per RFC4291).

- a subnet is a set of IP addresses that are on the same link (as
per RFC1884 and RFC950). These addresses are then on-link with respect to
this link. All other addresses are off-link.

- a link is the logical scope that layer 2 provides, for IP packet transfer
without TTL decrement, through a given interface.

- an interface is a node's attachment to a link (as per RFC4861).

Emmanuel

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 24 Nov 2008 12:17:18 +0100

- a subnet is a set of IP addresses that are on the same link (as per
RFC1884 and RFC950). These addresses are then on-link with respect to this
link. All other addresses are off-link.

[Teco:] RFC1884 is historic. RFC4291 is the current IPv6 Addressing
Architecture. 

Think about RFC3775  / 4887 and 4903 discussing the issues.

Do you think home addresses that are not on the home link are not part of
the subnet?

Teco.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 24 Nov 2008 11:24:45 -0800

Emmanuel Baccelli wrote:

> Thanks. So unless someone objects, there is indeed a consensus on the 
> terms below. The only question (raised by Charlie) was about the term 
> "subnet", but it is cleared with pointers to RFC1884 and RFC950 
> indicated by Erick:
> 
> - a link is what lower layers reach without TTL decrement, through a 
> given interface.

I think the usage of "subnet" in RFC950 assumes it is a prefix since it 
describes things using a bitmask.

But I don't think we actually need to refer to a definition of "subnet" 
for autoconf; that is important is that the prefix(es) from which 
addresses are configured are not on-link on any link.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 24 Nov 2008 11:28:08 -0800

Teco Boot wrote:

> *3.76 link: In the context of an IEEE 802.11 medium access control (MAC) 
> entity, a physical path consisting*
> 
> *of exactly one traversal of the wireless medium (WM) that is used to 
> transfer an MAC service data unit*
> 
> *(MSDU) between two stations (STAs).*

The IEEE 802 definition of a "link" is quite different than the 
definition in RFC 2460.

For example, if I have a host using 802.11 and it sends a packet via the 
AP onto an Ethernet and it passes via a 802.1D bridge before reaching 
the L2 destination, then it has traversed three "802 links"; one to get 
to the AP, one between the AP and the bridge, and one from the bridge to 
the L2 destination.

    Erik

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 24 Nov 2008 15:50:46 -0800

Hello Erik,

One more note related to the saga of "netmask".

>          the  subnet  part, which is taken from the host field of

I think there was an older definition for "netmask", because as I recall 
it was
possible for the netmask to specify noncontiguous bits of the address space.
Fortunately, it seemed that no sane person ever really tried to use it this
way, and the feature was subsequently deleted.

Surely there's some BSDv3 man pages out there somewhere :-)
(but I could not find them in the limited time I've had to look).

Regards,
Charlie P.

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 25 Nov 2008 11:12:28 +0100

Hi Erik,

> to the AP, one between the AP and the bridge, and one from the bridge

Agreed.
For addressing, it doesn't matter how many lower layer links are passed
between the on-link IPv6 nodes. 
But for MANET protocols, this is important.
Question is, do we produce a MANET Architecture for both MANET and Autoconf
WGs? Or just for Autoconf?

If its usage is solely for Autoconf and not for MANET, let's rename the
document to something else than MANET Architecture, as it could be very
confusing.

Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 25 Nov 2008 11:26:22 -0000

> WGs? Or just for Autoconf?

Absolutely definitely the former. Or rather, not for the WGs,
but to define the architecture of a MANET, in which routing
will use a MANET routing protocol (as developed in the MANET
WG) and address autoconfiguration, when needed, will use a
suitable protocol (specified by - it's an officially open
question whether new protocols are needed - the Autoconf WG).

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 30 Nov 2008 18:13:14 -0800

> way, and the feature was subsequently deleted.

Yes, but I don't think all support for non-contig netmasks have been 
purged from neither the standards nor the implementation. But since 
they've been removed in some places the effect of trying to use them 
would be quite unpredictable. In any case, they aren't useful.

    Erik