Subject: [Anima] FW: New Version Notification for draft-behringer-anima-autonomic-addressing-00.txt

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 22 Apr 2015 16:46:23 +0000

ANIMA, 

Looking at the reference model, addressing is an important part. I've been hesitating on how to put materials into the reference model that may still evolve in a different direction, and I think items such as addressing where we essentially need to settle on a common model may be better discussed outside the reference model for now. 

So, in the end I pushed the text as a separate draft for now, with the expectation that an addressing concept will merge into the reference model later on. But it will likely evolve from the below. 

So please read the below couple of pages in this light. It is documenting what Cisco's autonomic implementation is doing right now. There are many ways to do this, so I would encourage people with other ideas to also publish them (or at least send the proposed text to the list) so that we can have a fruitful discussion. 

Michael

PS: I published this doc yesterday, but forgot to add the "anima" in the title, so this one is just a re-post with the correct title. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 22 April 2015 10:34
> To: Michael Behringer (mbehring); Michael Behringer (mbehring)
> Subject: New Version Notification for draft-behringer-anima-autonomic-
> addressing-00.txt
> 
> 
> A new version of I-D, draft-behringer-anima-autonomic-addressing-00.txt
> has been successfully submitted by Michael H. Behringer and posted to the
> IETF repository.
> 
> Name:		draft-behringer-anima-autonomic-addressing
> Revision:	00
> Title:		An Autonomic IPv6 Addressing Scheme
> Document date:	2015-04-22
> Group:		Individual Submission
> Pages:		5
> URL:            http://www.ietf.org/internet-drafts/draft-behringer-anima-
> autonomic-addressing-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-behringer-anima-
> autonomic-addressing/
> Htmlized:       http://tools.ietf.org/html/draft-behringer-anima-autonomic-
> addressing-00
> 
> 
> Abstract:
>    This document describes a generic IPv6 addressing scheme which is
>    suitable for autonomic nodes, where node addressing must not depend
>    on a centrally managed scheme.  It assumes a unique domain name and
>    device name, and automatically derives a unique IPv6 address from
>    those.  The scheme allows for a flat address hierarchy as well as
>    optionally, when required, the definition of zones which are
>    aggregatable.  This document is for discussion right now; the final
>    addressing scheme should probably move into
>    [I-D.behringer-anima-reference-model].
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 23 Apr 2015 09:28:37 -0700

Thanks Michael

When planning for OSS AN implementation (SNBI), we see that we
would like to have multiple addresses per AN-node: 

AN nodes should hae an aggregateable address range:
- Agents in the AN-node could then have their own address and the
  basic forwarding element functions of AN (AN-FE) do not have to
  bother sharing the address.
- Implementations become a lot easier. Especially commercial
  implementations where additional agents or the like running
  in some VM would already today usually have different addresses
  than eg: the routers loopback address.
- When attaching AN to a NOC-LAN it would be great if the AN
  router could hand out addresses to the NOC machines automatically.
  These addresses toos hould be from the domains address range.
  That way we would have a very simple option for our security model.
 
So here is what i would propose:

  Type = 0: stays unchanged: Used for AN routers that can't do better
     
  Type = 1/2: New semantic:

    Device-ID:
      24-bit-OUI 8-bit-registrar-id 16-bit-device-id 16-bit-logical-node-address

  Explanation:
    16-bit-device ID as in the current draft, each enrolled AN device
    gets a different number. That device then has the last 16
    bits to assign to internal functions. 16-bit-logical-node-address 0
    must be used for the AN-FE function.

    Instead of 48 bits for registrar ID this leaves us with just 32 bits:
    24-bit-OUI + 8-bit registrar-ID. Keeping the OUI in the format allows
    for different vendors to figure out separately how to let users
    assign the registrar-ID when they have multiple.

  Each AN node has now 2 /112 bit address prefixes. Type 1 is for
  all "internal" functions. Internal means that those functions share
  the domain certificate of the AN-device (eg: agents).
  
  Type 2 is external equipment in the NOC to which the AN device
  handed out an address from its /112 block. These devices will
  use their own domain certificate. 

  There are still a bunch of important insecure protocols required in
  network OAM.  TFTP for example (yes i know there is a security option
  coming now... its just an example). AN devices can decide whether
  they want to permit such insecure protocols for example only if
  the device has a type 2 AN address because that indicates that
  an AN device did hand out out that Type 2 address. And one can
  even derive the Type 1 address of that AN device from the Type 2
  address and layer more security inside AN on this.

So in the end a lot more flexible use of those glorious 128 bits of
addressing, albeit at the expense of likely having to manually
assign  an 8-bit registrar-ID to every registrar manually. 

And this is just a suggestion - food for thought. Any improvements
welcome.

cheers
    Toerless

In commercial products this would make implementation even more
This would be likely even more worthwhile in commercial devices.
Agent would be running in some VM/container context and the
actual AN-router would certainly have more challenges handing
out the same IPv6 address it uses internally as loopback for
all its services (routing, ssh, SNMP,...). Sounds also security
wise as good separation.

Thirdly, imagine 
out the same IPv6 address that it uses as a key security

Imagine a commercial 
If we want to modularily split up autonomic forwarding (FE) from
autonomic agents, this can be done a lot easier when the agent
can have their own address. That allows to model them as one
or multiple IPv6 hosts beind a virtual internal network link
connected to the AN-FE.

it would help the AN goals a lot if individual AN nodes could get

On Wed, Apr 22, 2015 at 04:46:23PM +0000, Michael Behringer (mbehring) wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Apr 2015 08:27:11 +1200

Hi Toerless,

Excuse front posting, but this is a general comment since I think the
specifics depend on other discussions first.

You use the word "manually". I think that needs to be forbidden from
our vocabulary.

Regards
   Brian