home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
sipp
/
sipp-minutes-94feb.txt
< prev
next >
Wrap
Text File
|
1994-06-07
|
11KB
|
319 lines
INTERIM_MEETING_REPORT_
Reported by Bob Hinden/Sun Microsystems
Minutes of the Simple Internet Protocol Plus Working Group (SIPP)
Agenda
o Document status
o Implementation status
o Subnet model discussion
o Auto-configuration/Sue's drafts
o Bob's site prefix mask idea
o Ran's security Internet-Drafts
o Plans for next meeting
Document Status
Documents that have to get out as RFCs prior to the IETF meeting:
SIPP Done
IPAE Done, want to rev some items
Routing and Addr Done
ICMP/IGMP Needs to be completed
DHCP Changes Done
DNS Done, may update
SIPP White paper Done, may update based on comments
ARP Changes/Usage (see discussion later)
Documents that it would be nice to get out as RFCs:
Neighbor Discovery Draft available
Auto Config Draft available
OSPF for SIPP Done
API specification Needs to be updated for SIPP
SIPP RIP Needs to be completed
IDRP for SIPP Done
MIB Needs to be written
Action items: Bob Hinden will contact Marshall Rose for ``volunteer''
to do the SIPP MIB; Jim Bound, Bob Gilligan and Ramesh Govindan will
update the SIPP API specification in two weeks; Bob Gilligan will revise
the IPAE specification; and Ramesh Govindan will update and send out the
ICMP specification.
Implementation Status
Jim Bound is doing an OSF/1 implementation.
Larry Peterson's student is doing a SIPP X-Kernel implementation.
NRL is doing an implementation which includes the security headers.
JB suggested having an implementors meeting at the Seattle IETF meeting.
Steve Pink status?
Bellcore has 4.1.x implementation running for SIPP. Includes routing
headers, SIPP multicast, 64-bit addresses.
Need to start an SIPP-Bone deployment
CH: Would like to get changes made to the INRIA code so can use that as
a base for further work.
BG: Suggested it would be good to have one person/group to coordinate
BSD-based implementation.
JB: Thinks application should only see 64-bit addresses. Applies to API
work.
RG: Demo at IETF? No. BG: Should focus on doing implementation testing.
BG: Now has three machines running SIPP on Internet. Two at Sun, one at
PARC. We should start doing coordination among implementors, addresses,
Schedule a SIPP Connectathon? Yes, this is a good idea. A week in the
spring. CH: Also need to test routing protocols. Modify GateD
(SIPPD?).
Subnet Model
SD: Last year's assumption that we were going to an ES-IS areas type
scheme instead of the IP subnet model. In this model Subnet would
identify multiple physical wires. He had thought this would be a step
forward. After working on ROAD document, he discovered when working on
SIPP multicast, this approach gets very messy. Issue is that multicast
routing protocols using source based algorithms want to know where a
packet came from. A multihomed host would be required to send packets
out on each interface. Assumption is that routers have host routes.
This is harder because hosts may not have all similar addresses. The
ES-IS approach makes this much harder. Also had push back from John Moy
because it would be hard to do in OSPF, because it would consume one of
OSPF's levels.
SD proposed to go back to IP's subnet model where a single subnet can
only represent one link (note that a link can have multiple subnets).
If we do this, the questions is how to do address resolution. Can still
do 64-bit ARP, ARP like things query response mechanism, or ES-IS style
periodic advertisements.
BH: Keeping mechanism similar to IP is good. Less change for
administrators.
BG: This will make moving hosts harder. SD: Can be handled with
discovery and auto address assignment.
CH: Stay with approach like IP and handle mobile hosts as a special
case. Mobile hosts finds a router.
JB: Asked Steve to describe models SD: Allowing multiple links per
subnet requires hosts to inform router of their identity.
SD: Problem with multicast is that source sensitive multicast routing
uses source subnet number to identify source. This requires host to
send packets out each interface instead of only one. Current IP model
only requires host to only send out on one interface.
PF: The ES-IS also makes auto configuration harder if you are putting
subnet addresses in local use address when not using 802 addresses.
Decision: Group decided to revert to IP subnet model (away from ES-IS
area model). Will require changes to ROAD document. PF: Agreed to
modify ROAD specification.
Action: Francis: Modify to ROAD document to reflect decision to use IP
subnet model.
EN: Need to specify how multihomed host works.
SD: Two questions: (1) Originate a packet must it be sent over
interface that belongs to source address? (2) Should you refuse to
accept packet which arrives on wrong interface?
PF: Do not need to specify how multihomed hosts work now.
SD: What do do about ARP? Three are currently three proposals: (1)
64bit ARP, (2) ICMP query/response, and (3) periodic host
advertisements.
Plus one approach to use as part of a transition scheme: (0) 32bit ARP
with fixed prefix.
JB: Should we also document 0?
MC: What is wrong with existing ARP. BG: 32-bit ARP will not work with
64-bit SIPP. Need to do something new.
EN: Also noted that other mechanisms (router discovery and resolution,
redirect) include address resolution and are already in ICMP. CH:
Implementation is easier, it is in IP layer, no change to network
drivers, makes it easier to integrate routing lookup and the resolution
of network addresses.
Decision: After a lengthly discussion the group agreed to Approach 2
using ICMP Query/Response.
JB: Should we do mobile SIPP document? SD: No let work proceed in the
Mobile IP Working Group.
Auto Configuration
BootP extension to return SIPP address prefix. DHCP specifies that SIPP
prefix must be returned.
Auto Address Assignment/Configuration
Discussion of effect on DHCP. SD: Minimal changes, or SIPP version of
DHCP with all fields 64-bits etc.
Approach described in the current document can also be used for get IPAE
compatible addresses.
EN: Proposed using new SIPP mechanism for address assignment, people can
use DHCP for other configuration items. Take address assignment out of
DHCP for SIPP.
SD: Proposed separate protocols for address assignment from other
configuration items, and use DHCP for other information.
Decision: Group decided to proceed with Sue Thompson's auto host
address assignment approach.
Will want to later update DHCP to run over SIPP and update other
information in DHCP for SIPP devices.
ST: Wants another reviewer for her document.
Decision: Group decided that ICMP/IGMP specification should have the
packet formats for the neighbor and router discovery messages, but the
description of how they are used should be in Bill Simpsons document.
Bill Simpsons document should describe mechanisms for router discovery,
address resolution, and host redirects. Messages should include fields
for mobility but the document should not describe mobility mechanisms.
EN: Do we want to start assigning SIPP multicast addresses. We should
start separate multicast addresses. SD: Willing to be SIPP multicast
assigned number authority.
Do we want a SIPP assigned number ID? Erik Nordmark will write this
document.
Action: Nordmark: Write up SIPP assigned number document.
Site Prefix Mask
[Bill Simpson has raised objections to this in the past, but could not
attend this meeting.]
BG: Host need to decide what kind of packet to send (SIPP, IPAE, IPv4).
Current rules require packet to be either IPv4 or IPAE out of site
The current IPAE specification uses an algorithm that is based on high
order 32 bits to determine if destination is IP reachable or SIPP
reachable. This requires all SIPP nodes within same 32-bit prefix to be
within IPv4 connectivity.
BG proposed solution is to use a mask over the interface address to
determine IPv4 connectivity. All zero mask would mean that all
destinations are IPv4 reachable, all ones means all are SIPP reachable.
Bill Simpson previously raised concerned that this is another piece of
per node configuration information (per interface). Would need to put
this in auto-configuration information.
SD: Seems like the right thing to do. Believes answer to Bill's
concerns is to add this to router advertisement messages.
Long discussion of merits/problems. Some thought that this force
packets to be sent using IPv4 when it could be sent directly with SIPP.
BG: Think he can write down an algorithm which works, but might not
always send the optimal packet type.
SD: Thinks the masks are good to define IPv4 routability. EN: Notes the
that change to use the IP subnet model removes another mask, so adding
this one is a wash.
Group generally agreed to go with this, but needs some more fleshing out
on mailing list. BG will work out details of algorithm.
Ran's Security Internet-Drafts
This was not discussed because Ran Atkinson could not attend this
meeting.
Next Meeting
The next SIPP meeting will be at the Seattle IETF. Jim Bound would like
to set up a developers meeting at the IETF. Should there be a SIPP
Working Group dinner at the IETF?
Summary of Action Items
Hinden Contact Marshall Rose for ``volunteer'' to
do SIPP MIB
Bound/Gilligan/Govindan Update SIPP API specification in two weeks
Gilligan Revise IPAE specification
Govindan Send to SIPP List, update and send out ICMP
specification
Francis Modify to ROAD document to reflect decision
to use IP subnet model.
Nordmark Write up SIPP assigned number document.
Hinden Plan for Spring SIPPathon event
coordination. This would a mix of testing
over the Internet and a locations on east
and west coasts of the US and one in
Europe.
Summary of Decisions
o Group decided to revert to IP subnet model (away from ES-IS area
model). Will require changes to ROAD document. PF: Agreed to
modify ROAD specification.
o After a lengthly discussion the group agreed to using ICMP
Query/Response.
o Group decided to proceed with Sue Thompson's auto host address
assignment approach.
o Group decided that ICMP/IGMP specification should have the packet
formats for the neighbor and router discovery messages, but the
description of how they are used should be in Bill Simpsons
document.
Attendees
Jim Bound bound@zk3.dec.com
Matt Crawford crawdad@fncent.fnal.gov
Stephen Deering deering@parc.xerox.com
Paul Francis francis@cactus.slab.ntt.jp
Robert Gilligan Bob.Gilligan@Eng.Sun.Com
Ramesh Govindan rxg@thumper.bellcore.com
Robert Hinden hinden@eng.sun.com
Christian Huitema Christian.Huitema@sophia.inria.fr
Erik Nordmark nordmark@eng.sun.com
Susan Thomson set@bellcore.com